Середа, травня 25, 2016

Останні записи

Опублікував Автор: Створено: в Uncategorized
фаервол в LinuxДоброго времени, читатели и гости моего блога. C этой статьи начну серию статей о подсистеме Netfilter/iptables в Linux. В данной статье приведу основные понятия работы netfilter в Linux. Для понимания данной темы, обязательно советую ознакомиться со статьями Основные понятия сетей,Настройка сети в Linux, диагностика и мониторинг и Настройка и управление сетевой подсистемой Linux (iproute2).

Введение и история

Netfilter — межсетевой экран (он же, брандмауэр, он же файерволл, он же firewall...) встроен в ядро Linux с версии 2.4. Netfilter управляется утилитой iptables (Для IPv6 — ip6tables). До netfilter/iptablesбыл Ipchains, который входил в состав ядер Linux 2.2. До ipchains в Linux был так называемый ipfw(IPV4 firewal), перенесенный из BSD. Утилита управления - ipfwadm. Проект netfilter/iptables был основан в 1998. Автором является Расти Расселл (он же руководил и прошлыми разработками). В 1999 г. образовалась команда Netfilter Core Team (сокращено coreteam). Разработанный межсетевой экран получил официальное название netfilter. В августе 2003 руководителем coreteam стал Харальд Вельте (Harald Welte).

Проекты ipchains и ipfwadm изменяли работу стека протоколов ядра Linux, поскольку до появленияnetfilter в архитектуре ядра не существовало возможностей для подключения дополнительных модулей управления пакетами. iptables сохранил основную идею ipfwadm — список правил, состоящих из критериев и действия, которое выполняется если пакет соответствует критериям. В ipchains была представлена новая концепция — возможность создавать новые цепочки правил и переход пакетов между цепочками, а в iptables концепция была расширена до четырёх таблиц (в современных netfilter - более четырех), разграничивающих цепочки правил по задачам: фильтрация, NAT, и модификация пакетов. Также iptables расширил возможности Linux в области определения состояний, позволяя создавать межсетевые экраны работающие на сеансовом уровне.

Архитектура Netfilter/iptables

Предварительные требования (с)

Как уже говорилось выше, для работы Netfilter необходимо ядро версии 2.6 (ну или хотя бы 2.3.15). Кроме того, при сборке и настройке ядра необходимо наличие настроек CONFIG_NETFILTER, CONFIG_IP_NF_IPTABLES, CONFIG_IP_NF_FILTER (таблица filter), CONFIG_IP_NF_NAT (таблица nat), CONFIG_BRIDGE_NETFILTER, а также многочисленные дополнительные модули: CONFIG_IP_NF_CONNTRACK (отслеживание соединений), CONFIG_IP_NF_FTP (вспомогательный модуль для отслеживания FTP соединений), CONFIG_IP_NF_MATCH_* (дополнительные типы шаблонов соответствия пакетов: LIMIT, MAC, MARK, MULTIPORT, TOS, TCPMSS, STATE, UNCLEAN, OWNER), CONFIG_IP_NF_TARGET_* (дополнительные действия в правилах: REJECT, MASQUERADE, REDIRECT, LOG, TCPMSS), CONFIG_IP_NF_COMPAT_IPCHAINS для совместимости с ipchains, CONFIG_BRIDGE_NF_EBTABLES и CONFIG_BRIDGE_EBT_* для работы в режиме моста, прочие CONFIG_IP_NF_* и CONFIG_IP6_NF_*. Полезно также указать CONFIG_PACKET.

Файлы в каталоге /proc, отображающие информацию о работе netfilter (о некоторых из них - ниже по тексту):

  • /proc/net/ip_tables_names - список используемых таблиц
  • /proc/net/ip_tables_targets - список используемых действий
  • /proc/net/ip_tables_matches - список используемых протоколов
  • /proc/net/nf_conntrack (или /proc/net/ip_conntrack) - список установленных соединений и ихсостояний
  • /proc/sys/net/ipv4/netfilter/* - cодержит множество настроек системы conntrack, например:
    • ip_conntrack_tcp_be_liberal
      • 0 - все пакеты, не попадающие в окно, считаются INVALID
      • 1 - только RST пакеты, не попадающие в окно, считаются INVALID (пришлось поставить)
    • ip_conntrack_log_invalid - выводить в журнал INVALID пакеты
    • ip_conntrack_tcp_loose - при "подхватывании" уже установленного соединения сколько пакетов требуется в обоих направлениях для подтверждения; если 0, то установленное соединение не подхватывается вовсе; по умолчанию - 3
    • ip_conntrack_max_retrans - число повторных пакетов без подтверждения ACK, которое требуется для удаления соединения из таблицы после дополнительного ожидания ip_conntrack_timeout_max_retrans секунд; по умолчанию - 3
Функциональность netfilter может расширяться с помощью модулей ядра. Головной модуль ядра называется iptable_filter, модуль поддержки утилиты iptables называется ip_tables, вспомогательные модули обычно имеют префикс "ipt_" (например: ipt_state, ipt_REJECT, ipt_LOG; хотя - ip_conntrack/nf_conntrack). Большинство модулей загружается автомагически, но некоторые всё же приходиться загружать вручную (ip_conntrack_ftp - иначе может не работать в режиме Active; ip_conntrack_irc - иначе может не работать отсылка файлов по DCC; ip_nat_ftp; ip_nat_irc; ip_conntrack_tftp/nf_conntrack_tftp на клиенте - иначе не будет работать TFTP).

Схема работы

Для начального понимания архитектуры Netfilter/iptables отлично подойдет иллюстрация из википедии, которую я несколько модифицировал для большей прозрачности и понимания материала:

Архитектура netfiler/iptables в схеме

Ахтунг, ниже в трех абзацах изложена основная мысль статьи и принцип работы сетевого фильтра, поэтому желательно вчитаться как можно внимательнее!

Итак, давайте разберем данную схему работы netfilter. Сетевые пакеты поступают в сетевой интерфейс, настроенный на стек TCP/IP и после некоторых простых проверок ядром (например, контрольная сумма) проходят  последовательность цепочек (chain) (обозначены пунктиром). Пакет обязательно проходит первоначальную цепочку PREROUTING. После цепочки PREROUTING, в соответствии с таблицей маршрутизации, проверяется кому принадлежит пакет и, в зависимости от назначения пакета, определяется куда он дальше попадет (в какую цепочку). Если пакет НЕ адресован (в TCP пакете поле адрес получателя - НЕ локальная система) локальной системе, то он направляется в цепочку FORWARD, если пакет адресован локальной системе, то направляется в цепочку INPUT и после прохождения INPUTотдается локальным демонам/процессам. После обработки локальной программой, при необходимости формируется ответ. Ответный пакет пакет отправляемый локальной системой в соответствии с правилами маршрутизации направляется на соответствующий маршрут (хост из локальной сети или адрес маршрутизатора) и направляется в цепочку OUTPUT. После цепочки OUTPUT (или FORWARD, если пакет был проходящий) пакет снова сверяется с правилами маршрутизации и отправляется в цепочкуPOSTROUTING. Может возникнуть резонный вопрос: почему несколько раз пакет проходит через таблицу маршрутизации? (об этом - ниже).

Каждая цепочка, которую проходит пакет состоит из набора таблиц (table) (обозначены овалами).Таблицы в разных цепочках имеют одинаковое наименование, но тем не менее никак между собой не связаны. Например таблица nat в цепочке PREROUTING никак не связана с таблицей nat в цепочкеPOSTROUTINGКаждая таблица состоит из упорядоченного  набора (списка) правилКаждое правилосодержит условие, которому должен соответствовать проходящий пакет и действия к пакету, подходящему данному условию.

Проходя через серию цепочек пакет последовательно проходит каждую таблицу (в указанном на иллюстрации порядке) и в каждой таблице последовательно сверяется с каждым правилом (точнее сказать - с каждым набором условий/критериев в правиле), и если пакет соответствует какому-либокритерию, то выполняется заданное действие над пакетом. При этом, в каждой таблице (кроме пользовательских) существует заданная по-умолчанию политика. Данная политика определяет действие над пакетом, в случае, если пакет не соответствует ни одному из правил в таблице. Чаще всего - это действие ACCEPT, чтобы принять пакет и передать в следующую таблицу или DROP - чтобы отбросить пакет. В случае, если пакет не был отброшен, он завершает свое путешествие по ядру системы и отправляется в сетевую карту сетевой интерфейс, которая подходит по правилам маршрутизации.

Очень часто о таблицах и цепочках говорят в плоскости "таблицы содержат  в себе наборы цепочек", но я считаю, что это неудобно и непонятно.

Цепочки netfilter:

  • PREROUTING — для изначальной обработки входящих пакетов
  • INPUT — для входящих пакетов, адресованных непосредственно локальному компьютеру
  • FORWARD — для проходящих (маршрутизируемых) пакетов
  • OUTPUT — для пакетов, создаваемых локальным компьютером (исходящих)
  • POSTROUTING— для окончательной обработки исходящих пакетов
  • Также можно создавать и уничтожать собственные цепочки при помощи утилиты iptables.

Цепочки организованны в 4 таблицы:

  • raw — пакет проходит данную таблицу до передачи системе определения состояний. Используется редко, например для маркировки пакетов, которые НЕ должны обрабатываться системой определения состояний. Для этого в правиле указывается действие NOTRACK. Содержитcя в цепочкахPREROUTING и OUTPUT.
  • mangle — содержит правила модификации (обычно полей заголовка) IP‐пакетов. Среди прочего, поддерживает действия TTLTOS, и MARK (для изменения полей TTL и TOS, и для изменения маркеров пакета). Редко необходима и может быть опасна. Содержится во всех пяти стандартных цепочках.
  • nat — предназначена для подмены адреса отправителя или получателя. Данную таблицу проходят только первый пакет из потока, трансляция адресов или маскировка (подмена адреса отправителя или получателя) применяются ко всем последующим пакетам в потоке автоматически. Поддерживает действия DNATSNATMASQUERADE, REDIRECT. Содержится в цепочкахPREROUTINGOUTPUT, и POSTROUTING.
  • filter — основная таблица, используется по умолчанию если название таблицы не указано. Используется для фильтрации пакетов. Содержится в цепочках INPUTFORWARD, и OUTPUT.
Как я уже отметил, непосредственно для фильтрации пакетов используются таблицЫ filter. Поэтому в рамках данной темы важно понимать, что для пакетов, предназначенных данному узлу необходимо модифицировать таблицу filter цепочки INPUT, для проходящих пакетов — цепочки FORWARD, для пакетов, созданных данным узлом — OUTPUT.

Примеры прохождения цепочек

Последовательность обработки входящего пакета, предназначенного для локального процесса:

  1. Просматривается цепочка PREROUTING
    1. Просматривается таблица raw
    2. Просматривается  таблица mangle, далее происходит отслеживание соединений
    3. Просматривается таблица nat (используется для DNAT - модификация адреса получателя)
  2. маршрутизация: если пакет надо маршрутизовать мимо локального хоста, то переходим к обработкепроходящего пакета, если для он предназначен локальному хосту, то обрабатывается как локальный
  3. Просматривается цепочка INPUT 
    1. Просматривается таблица mangle
    2. Просматривается таблица filter
Последовательность обработки пакета, уходящего с нашего хоста:

  1. Маршрутизация: определение исходящего адреса, адреса назначения, используемого интерфейса; если пакет маршрутизируется внутрь (для локального хоста), то переходим к предыдущей процедуре
  2. Просматривается цепочка OUTPUT
    1. Просматривается таблица raw
    2. Просматривается таблица mangle, фильтровать здесь не стоит, здесь же происходит отслеживание локально создаваемых соединений
    3. Просматривается таблица nat (NAT для локально сгенерированных пакетов)
    4. Просматривается таблица filter
  3. Повторная маршрутизация, т.к. в таблицах mangle и nat пакет мог быть изменён; если пакет маршрутизируется внутрь (для локального хоста), то переходим к предыдущей процедуре
  4. Просматривается цепочка POSTROUTING 
    1. Просматривается таблица mangle
    2. Просматривается таблица nat (используется для SNAT - модификация адреса источника, фильтровать здесь не стоит)
Последовательность обработки проходящего пакета (начинается от п.2 первой процедуры):

  1. Просматривается цепочка FORWARD
    1. Просматривается таблица mangle
    2. Просматривается таблица filter
  2. повторная маршрутизация, т.к. в таблице mangle пакет мог быть изменён; если пакет маршрутизируется внутрь (для локального хоста), то переходим к первой процедуре
  3. Просматривается цепочка POSTROUTING
    1. Просматривается таблица mangle
    2. Просматривается таблица nat (используется для SNAT и Masquerading, фильтровать здесь не стоит)
Как видно, таблица nat и mangle может модифицировать получателя или отправителя сетевого пакета. Именно поэтому сетевой пакет несколько раз сверяется с таблицей маршрутизации.

Механизм определения состояний (conntrack)

Выше в тексте несколько раз указывалось понятие "определение состояний", оно заслуживает отдельной темы для обсуждения, но тем не менее я кратко затрону данный вопрос в текущем посте. В общем, механизм определения состояний (он же state machine, он же connection tracking, он же conntrack) является частью пакетного фильтра и позволяет определить определить к какому соединению/сеансу принадлежит пакет. Conntrack анализирует состояние всех пакетов, кроме тех, которые помечены какNOTRACK в таблице raw. На основе этого состояния определяется принадлежит пакет новомусоединению (состояние NEW), уже установленному соединению (состояние ESTABLISHED),дополнительному к уже существующему (RELATED), либо к "другому" (неопределяемому) соединению (состояние INVALID). Состояние пакета определяется на основе анализа заголовков передаваемого TCP-пакета. Модуль conntrack позволяет реализовать межсетевой экран сеансового уровня (пятого уровня модели OSI). Для управления данным механизмом используется утилита conntrack, а так же параметр утилиты iptables: -m conntrack или -m state (устарел). Состояния текущих соединений conntrack хранит в ядре. Их можно просмотреть в файле /proc/net/nf_conntrack (или /proc/net/ip_conntrack).

Чтобы мысли не превратились в кашу, думаю данной краткой информации для понимания дальнейшего материала будет достаточно.

Управление правилами сетевой фильтрации Netfilter (использование команды iptables)

Утилита iptables является интерфейсом для управления сетевым экраном netfilter. Данная команда позволяет редактировать правила таблиц, таблицы и цепочки. Как я уже говорил - каждое правилопредставляет собой запись/строку, содержащую в себе критерии отбора сетевых пакетов и действие над пакетами, которые соответствуют заданному правилу. Команда iptables требует для своей работы прав root.

В общем случае формат команды следующий:

iptables [-t таблица] команда [критерии] [действие]Все параметры в квадратных скобках - необязательны. По умолчанию используется таблица filter, если же необходимо указать другую таблицу, то следует использовать ключ -t с указанием имени таблицы. После имени таблицы указывается команда, определяющая действие (например: вставить правило, или добавить правило в конец цепочки, или удалить правило). "критерии" задает параметры отбора. "действие" указывает, какое действие должно быть выполнено при условии совпадения критериев отбора в правиле (например: передать пакет в другую цепочку правил, "сбросить" пакет, выдать на источник сообщение об ошибке...).

Ниже приведены команды и параметры утилиты iptables:

ПараметрОписаниеПример
Команды
--append (-A) Добавить в указанную цепочку и указанную таблицу заданное правило в КОНЕЦ списка. iptables -A FORWARD критерии -j действие
--delete (-D) Удаляет заданное номером(ами) или правилом(ами) правило(а). Первый пример удаляет все правила с номерами 10,12 во всех цепочках, в таблицах filter, второй пример удаляет заданное правило из таблицы mangle в цепочке PREROUTING. iptables -D 10,12
iptables -t mangle -D PREROUTING критерии -j действие
--rename-chain (-E) Изменить имя цепочки. iptables -E OLD_CHAIN NEW_CHAIN
--flush (-F) Очистка всех правил текущей таблицы. Ко всем пакетам, которые относятся к уже установленным соединениям, применяем терминальное действие ACCEPT — пропустить iptables -F
--insert (-I) Вставляет заданное правило в место, заданное номером. iptables -I FORWARD 5 критерии -j действие
--list (сокр. -L) Просмотр существующих правил (без явного указания таблицы - отображается таблица filter всех цепочек). iptables -L
--policy (-P) Устанавливает стандартную политику для заданной цепочки. iptables -t mangle -P PREROUTING DROP
--replace (-R) Заменяет заданное номером правило на заданное в критериях. iptables -R POSROUTING 7 | критерии -j действие
--delete-chain (-X) Удалить ВСЕ созданные вручную цепочки (оставить только стандартные INPUT, OUTPUT, FORWARD, PREROUTING и POSTROUTING). iptables -X
--zero (-Z) Обнуляет счетчики переданных данных в цепочке. iptables -Z INPUT
Параметры
--numeric (-n) Не резолвит адреса и протоколы при выводе.
--line-numbers Указывать номера правил при выводе (может использоваться совместно с -L). iptables -L --line-numbers
--help (-h) куда же без нее :)
-t таблица Задает название таблицы, над которой необходимо совершить действие. В примере сбрасывается таблица nat во всех цепочках. iptables -t nat -F
--verbose (-v) Детальный вывод. iptables -L -v

Критерии (параметры) отбора сетевых пакетов команды iptables

Критерии отбора сетевых пакетов негласно делятся на несколько групп: Общие критерии, Неявные критерии, Явные критерии. Общие критерии допустимо употреблять в любых правилах, они не зависят от типа протокола и не требуют подгрузки модулей расширения. Неявные критерии (я бы из назвалнеобщие),  те критерии, которые подгружаются неявно и становятся доступны, например при указании общего критерия --protocol tcp|udp|icmp. Перед использованием Явных критериев, необходимо подключить дополнительное расширение (это своеобразные плагины для netfilter).Дополнительные расширения подгружаются с помощью параметра -m или --match. Так, например, если мы собираемся использовать критерии state, то мы должны явно указать это в строке правила: -m state левее используемого критерия. Отличие между явными и неявными необщими критериями заключается в том, что явные нужно подгружать явно, а неявные подгружаются автоматически.

Во всех критериях можно использовать знак ! перед значением критерия. Это будет означать, что под данное правило подпадают все пакеты, которые не соответствуют данному параметруНапример: критерий --protocol ! tcp будет обозначать, что все пакеты, которые не являются TCP-протоколом подходят под действие правила. Однако последние версии iptables (в частности, 1.4.3.2 и выше), уже не поддерживают этот синтаксис и требуют использования не --protocol ! tcp, а ! --protocol tcp,  выдавая следующую ошибку:

Using intrapositioned negation (`--option ! this`) is deprecated in favor of extrapositioned (`! --option this`).Ниже в виде таблицы приведены часто используемые параметры отбора пакетов:

ПараметрОписаниеПример
Общие параметры
--protocol
(сокр. -p)
Определяет протокол транспортного уровня. Опции tcp, udp, icmp, all или любой другой протокол определенный в /etc/protocols iptables -A INPUT -p tcp
--source
(-s, --src)
IP адрес источника пакета. Может быть определен несколькими путями:

  • Одиночный хост: host.domain.tld, или IP адрес: 10.10.10.3
  • Пул-адресов (подсеть): 10.10.10.3/24 или 10.10.10.3/255.255.255.0
Настойчиво не рекомендуется использовать доменные имена, для разрешения (резольва) которых требуются DNS-запросы, так как на этапе конфигурирования netfilter DNS может работать некорректно. Также, заметим, имена резольвятся всего один раз — при добавлении правила в цепочку. Впоследствии соответствующий этому имени IP-адрес может измениться, но на уже записанные правила это никак не повлияет (в них останется старый адрес). Если указать доменное имя, которое резольвится в несколько IP-адресов, то для каждого адреса будет добавлено отдельное правило.
iptables -A INPUT -s 10.10.10.3
--destination
(-d)
IP адрес назначения пакета. Может быть определен несколькими путями (см. --source). iptables -A INPUT --destination 192.168.1.0/24
--in-interface
(-i)
Определяет интерфейс, на который прибыл пакет. Полезно для NAT и машин с несколькими сетевыми интерфейсами. Применяется в цепочках INPUT, FORWARD и PREROUTING. Возможно использование знака "+", тогда подразумевается использование всех интерфейсов, начинающихся на имя+ (например eth+ - все интерфейсы eth). iptables -t nat -A PREROUTING --in-interface eth0
--out-interface
(-o)
Определяет интерфейс, с которого уйдет пакет. Полезно для NAT и машин с несколькими сетевыми интерфейсами. Применяется в цепочках OUTPUT, FORWARD и POSTROUTING. Возможно использование знака "+". iptables -t nat -A POSTROUTING --in-interface eth1
Неявные (необщие) параметры
-p proto -h вывод справки по неявным параметрам протокола proto. iptables -p icmp -h
--source-port
(--sport)
Порт источник, возможно только для протоколов --protocol tcp, или --protocol udp iptables -A INPUT --protocol tcp --source-port 25
--destination-port
(--dport)
Порт назначения, возможно только для протоколов --protocol tcp, или --protemocol udp iptables -A INPUT --protocol udp --destination-port 67
Явные параметры
-m state --state (устарел)
он же
-m conntrack --ctstate
Состояние соединения. Доступные опции:

  • NEW (Все пакеты устанавливающие новое соединение)
  • ESTABLISHED (Все пакеты, принадлежащие установленному соединению)
  • RELATED (Пакеты, не принадлежащие установленному соединению, но связанные с ним. Например - FTP в активном режиме использует разные соединения для передачи данных. Эти соединения связаны.)
  • INVALID (Пакеты, которые не могут быть по тем или иным причинам идентифицированы. Например, ICMP ошибки не принадлежащие существующим соединениям)
  • и др. (более подробно в документации)
iptables -A INPUT -m state --state NEW,ESTABLISHEDiptables -A INPUT -m conntrack --ctstate NEW,ESTABLISHED
-m mac --mac-source Задает MAC адрес сетевого узла, передавшего пакет. MAC адрес должен указываться в форме XX:XX:XX:XX:XX:XX. -m mac --mac-source 00:00:00:00:00:0

Действия над пакетами

Данный заголовок правильнее будет перефразировать в "Действия над пакетами, которые совпали с критериями отбора". Итак, для совершения какого-либо действия над пакетами, необходимо задать ключ -j (--jump) и указать, какое конкретно действие совершить.

Действия над пакетами могут принимать следующие значения:

  • ACCEPT - пакет покидает данную цепочку и передается в следующую (дословно - ПРИНЯТЬ).
  • DROP - отбросить удовлетворяющий условию пакет, при этом пакет не передается в другие таблицы/цепочки.
  • REJECT - отбросить пакет, отправив отправителю ICMP-сообщение, при этом пакет не передается в другие таблицы/цепочки.
  • RETURN - возвратить пакет в предыдущую цепочку и продолжить ее прохождение начиная со следующего правила.
  • SNAT - применить трансляцию адреса источника в пакете. Может использоваться только в цепочках POSTROUTING и OUTPUT в таблицах nat.
  • DNAT - применить трансляцию адреса назначения в пакете. Может использоваться в цепочкеPREROUTING в таблице nat. (в исключительных случаях - в цепочке OUTPUT)
  • LOG - протоколировать пакет (отправляется демону syslog) и обработать остальными правилами.
  • MASQUERADE — используется вместо SNAT при наличии соединения с динамическим IP (допускается указывать только в цепочке POSTROUTING таблицы nat).
  • MARK — используется для установки меток на пакеты, передается для обработки дальнейшим правилам.
  • и др.
Кроме указанных действий, существуют и другие, с которыми можно ознакомиться в документации (возможно, в скором времени я дополню статью в ходе освоения темы). У некоторых действий есть дополнительные параметры.

В таблице ниже приведены примеры и описания дополнительных параметров:

ПараметрОписаниеПример
DNAT (Destination Network Address Translation)
--to-destination указывает, какой IP адрес должен быть подставлен в качестве адреса места назначения. В примере во всех пакетах протокола tcp, пришедших на адрес 1.2.3.4, данный адрес будет заменен на 4.3.2.1. iptables -t nat -A PREROUTING -p tcp -d 1.2.3.4 -j DNAT --to-destination 4.3.2.1
LOG
--log-level Используется для задания уровня журналирования (log level). В примере установлен максимальный уровень логирования для всех tcp пакетов в таблице filter цепочки FORWARD. iptables -A FORWARD -p tcp -j LOG --log-level debug
--log-prefix Задает текст (префикс), которым будут предваряться все сообщения iptables. (очень удобно для дальнейшего парсинга) Префикс может содержать до 29 символов, включая и пробелы. В примере отправляются в syslog все tcp пакеты в таблице filter цепочки INPUT с префиксом INRUT-filter. iptables -A INPUT -p tcp -j LOG --log-prefix "INRUT-filter"
--log-ip-options Позволяет заносить в системный журнал различные сведения из заголовка IP пакета. iptables -A FORWARD -p tcp -j LOG --log-ip-options
и др...
На этом закончим теорию о сетевом фильтре netfilter/iptables. В следующей статье я приведу практические примеры для усвоения данной теории.

Резюме

В данной статье мы рассмотрели очень кратко основные понятия сетевого фильтра в Linux. Итак, подсистема netfilter/iptables является частью ядра Linux и используется для организации различных схем фильтрации и манипуляции с сетевыми пакетами. При этом, каждый пакет проходит от сетевого интерфейса, в который он прибыл и далее по определенному маршруту цепочек, в зависимости от того, предназначен он локальной системе или "нелокальной". Каждая цепочка состоит из набора таблиц, содержащих последовательный набор правил. Каждое правило состоит из определенного критерия/критериев отбора сетевого пакета и какого-то действия с пакетом, соответствующего данным критериям. В соответствии с заданными правилами над пакетом может быть совершено какое-либо действие (Например, передача следующей/другой цепочке, сброс пакета, модификация содержимого или заголовков и др.).  Каждая цепочка и каждая таблица имеет свое назначение, функциональность и место в пути следования пакета. Например для фильтрации пакетов используется таблица filter, которая содержится в трех стандартных цепочках и может содержаться в цепочках, заданных пользователем. Завершается путь пакета либо в выходящем сетевом интерфейсе, либо доставкой локальному процессу/приложению.

Литература

Довольно много интересной информации на русском содержится тут:

Более глубоко материал доступен на буржуйском вот тут:
Переглядів: 6
0

Опублікував Автор: Створено: в Uncategorized

https://access.redhat.com/solutions/255093

 

Issue

  • We're planning to purchase and roll out a bunch of new servers loaded up with solid-state disks in hardware-raid configurations and want to get some definitive answers from Red Hat regarding the statements below from the RHEL 6 Storage Administration Guide, i.e., does any of it apply to hardware raid?

    In addition, keep in mind that MD (software raid) does not support discards. In contrast, the logical volume manager (LVM) and the device-mapper (DM) targets that LVM uses do support discards. The only DM targets that do not support discards are dm-snapshot, dm-crypt, and dm-raid45. Discard support for the dm-mirror was added in Red Hat Enterprise Linux 6.1.

    Red Hat also warns that software RAID levels 1, 4, 5, and 6 are not recommended for use on SSDs. During the initialization stage of these RAID levels, some RAID management utilities (such as mdadm) write to all of the blocks on the storage device to ensure that checksums operate properly. This will cause the performance of the SSD to degrade quickly.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-ssd.html

Переглядів: 37
0

Опублікував Автор: Створено: в Uncategorized

echo writemostly >  /sys/block/md127/md/dev-sde1/state

You can enable "write-mostly" for a RAID component in the following way:

echo writemostly > /sys/block/md6/md/dev-sdc6/state and disable it this way:

echo -writemostly > /sys/block/md6/md/dev-sdc6/state If for some reason you cannot set a component of a RAID1 to "write-mostly", you can kick it from the array and re-add it with the write-mostly flag active. This will temporarily lower your redundancy level. Backup before doing this is recomended.

To set /dev/sdc6 from the last example to "write-mostly" would work as follows:

To kick, first set it to "faulty":

mdadm --fail /dev/md6 /dev/sdc6 Then kick it:mdadm --remove /dev/md6 /dev/sdc6 Then add it again:mdadm --add /dev/md6 --write-mostly /dev/sdc6 Wait for the RAID1 resync to complete, and /dev/sdc6 will now only be read when needed.

Переглядів: 40
0

Опублікував Автор: Створено: в Uncategorized

https://www.prosinger.net/upgrading-postfix-centos-6-x/

 

(updated Feb 29th 2016)

One problem that can comes up with the fantastic Centos Linux distro is that it sticks to the proven but also old packages. I needed some newer features several times. The only (good) way to upgrade Postfix to the newest package is to build it up from the source.

First, we need the link to the newest package (take a look here). In my case, it’s 2.11 stable, so let’s download it:

cd wget http://cdn.postfix.johnriley.me/mirrors/postfix-release/official/postfix-3.1.0.tar.gz tar xvf postfix-3.1.0.tar.gz cd postfix-3.1.0Now we need to isntall the development packages and the dependencies. These are the packages that I needed but You might need to install more, depending on which features You want to compile into it. For a standard featured Postfix MTA with SASL and MySQL support you’ll need the following:

yum install libdb-devel db4-devel cyrus-sasl cyrus-sasl-devel openssl openssl-devel pcre pcre-devel openldap openldap-devel mysql-develLet’s celan up the makefiles now, and build new ones (because by the supplied makefile Postfix won’t be compiled with SASL and SQL support), and at the end let’s build the whole package:

make clean make tidy make makefiles CCARGS='-fPIC -DUSE_TLS -DUSE_SSL -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -DPREFIX=\\"/usr\\" -DHAS_LDAP -DLDAP_DEPRECATED=1 -DHAS_PCRE -I/usr/include/openssl -DHAS_MYSQL -I/usr/include/mysql -I/usr/include/sasl -I/usr/include' AUXLIBS='-L/usr/lib64 -L/usr/lib64/openssl -lssl -lcrypto -L/usr/lib64/mysql -lmysqlclient -L/usr/lib64/sasl2 -lsasl2 -lpcre -lz -lm -lldap -llber -Wl,-rpath,/usr/lib64/openssl -pie -Wl,-z,relro' OPT='-O' DEBUG='-g' makeThe last step (build) will take a while, depeding on the CPU power of Your Linux box. At this moment, if it maneges to build without errors, you’ll have a ready to upgrade package. If not, you will need to yum groupinstall “Development Tools” and retry.

Regarding the arguments about building the makefile (step 3 above), depending on the features You want built in the new Postfix package please refer to the chapter 4.4 of the Postfix documentation. Basically, I never needed anything more than this, except that sometimes I want to use PgSQL instead of MySQL, then you will need to yum install postgresql-devel package and insert the correct arguments when creating the makefile.

One more note: creating the makefile in this example is done for Centos 6.x x64. If you are building for the 32-bit verion you will have to replace all the /usr/lib64 arguments with /usr/lib.

If everything is errorless, perform the update:

make upgradeDone. Please also read the suggested articles during install about the new features, and sugested changes to the master.cf and main.cf files.
Regarding the package, since You done it by compiling from the source, the RPM package will stay at version 2.6.x but when you finally do a service postfix restart you will see:

Dec 3 09:23:56 one postfix/master[31460]: daemon started — version 3.0.3, configuration /etc/postfix

Good luck!

...
Позначки: postfix
Переглядів: 89
0

Опублікував Автор: Створено: в Uncategorized
916 echo -e -n "\x50" > /dev/ttyUSB0
917 echo -e -n "\x51" > /dev/ttyUSB0
918 echo -e -n "\x04" > /dev/ttyUSB0
919 echo -e -n "\x51" > /dev/ttyUSB0
920 echo -e -n "\x04" > /dev/ttyUSB0
921 echo -e -n "\x51" > /dev/ttyUSB0
922 echo -e -n "\x04" > /dev/ttyUSB0
923 echo -e -n "\x50" > /dev/ttyUSB0
924 echo -e -n "\x04" > /dev/ttyUSB0
925 echo -e -n "\xff" > /dev/ttyUSB0
926 echo -e -n "\x04" > /dev/ttyUSB0
927 echo -e -n "\xff" > /dev/ttyUSB0
928 echo -e -n "\x04" > /dev/ttyUSB0
929 echo -e -n "\x50" > /dev/ttyUSB0
930 echo -e -n "\xff" > /dev/ttyUSB0
931 echo -e -n "\x04" > /dev/ttyUSB0
932 echo -e -n "\xff" > /dev/ttyUSB0
933 echo -e -n "\x04" > /dev/ttyUSB0
934 echo -e -n "\x50" > /dev/ttyUSB0
935 echo -e -n "\x04" > /dev/ttyUSB0
936 echo -e -n "\x51" > /dev/ttyUSB0
937 echo -e -n "\x04" > /dev/ttyUSB0
938 echo -e -n "\x51" > /dev/ttyUSB0
939 echo -e -n "\x04" > /dev/ttyUSB0
940 echo -e -n "\x51" > /dev/ttyUSB0
941 echo -e -n "\x04" > /dev/ttyUSB0
942 echo -e -n "\x50" > /dev/ttyUSB0
943 echo -e -n "\x04" > /dev/ttyUSB0
944 echo -e -n "\x50" > /dev/ttyUSB0
945 echo -e -n "\x51" > /dev/ttyUSB0
946 echo -e -n "\x04" > /dev/ttyUSB0
947 echo -e -n "\x50" > /dev/ttyUSB0
948 echo -e -n "\x04" > /dev/ttyUSB0
949 echo -e -n "\x50" > /dev/ttyUSB0
950 echo -e -n "\x04" > /dev/ttyUSB0
951 echo -e -n "\x50" > /dev/ttyUSB0
952 echo -e -n "\x04" > /dev/ttyUSB0
953 echo -e -n "\x50" > /dev/ttyUSB0
954 echo -e -n "\x04" > /dev/ttyUSB0
955 echo -e -n "\x50" > /dev/ttyUSB0
956 echo -e -n "\x51" > /dev/ttyUSB0
957 echo -e -n "\x04" > /dev/ttyUSB0
958 echo -e -n "\x50" > /dev/ttyUSB0
959 echo -e -n "\x04" > /dev/ttyUSB0
960 echo -e -n "\x50" > /dev/ttyUSB0
961 echo -e -n "\x51" > /dev/ttyUSB0
962 echo -e -n "\x04" > /dev/ttyUSB0
963 echo -e -n "\x51" > /dev/ttyUSB0
964 echo -e -n "\x04" > /dev/ttyUSB0
965 echo -e -n "\x51" > /dev/ttyUSB0
966 echo -e -n "\x04" > /dev/ttyUSB0
967 echo -e -n "\x51" > /dev/ttyUSB0
Переглядів: 167
0

Опублікував Автор: Створено: в Uncategorized

 

root@ismo:~# dmesg |grep command [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-25-generic root=UUID=b59249ce-9490-400d-a435-4c6669cb53ed ro splash libata.dma=0

 

[root@sol-fttb ~]# hdparm -tT /dev/sdf

/dev/sdf:
Timing cached reads: 17890 MB in 2.00 seconds = 8953.05 MB/sec
Timing buffered disk reads: 320 MB in 3.01 seconds = 106.40 MB/sec
You have new mail in /var/spool/mail/root
[root@sol-fttb ~]# hdparm -tT /dev/sdg

/dev/sdg:
Timing cached reads: 17310 MB in 2.00 seconds = 8662.82 MB/sec
Timing buffered disk reads: 300 MB in 3.12 seconds = 96.25 MB/sec
[root@sol-fttb ~]#

...
Переглядів: 320
0

Опублікував Автор: Створено: в Uncategorized

hdparm -I /dev/sdf

NCQ (англ. Native Command Queuing — апаратна установка черговості команд) — технологія, що використовується в SATA-пристроях починаючи з SATA/300 для підвищення швидкодії. Пристрої з підтримкою NCQ здатні приймати декілька запитів одночасно та реорганізовувати порядок їх виконання для досягнення максимальної ефективності (продуктивності) з урахуванням внутрішньої архітектури пристрою (мінімізуючи кількість переміщень головок та очікування потрібного сектора на треку). NCQ підвищує продуктивність завдань, пов'язаних з довільним читанням, обробкою даних від двох і більше джерел, одночасну роботу декількох програм. (Типове навантаження для сервера — одночасне виконання запитів від декількох клієнтів).

You may disable NCQ, and use normal READ/WRITE DMA commands, by setting the queue depth to 1:

...
Переглядів: 309
0

Опублікував Автор: Створено: в Uncategorized

cd /usr/local/lib/node_modules/mysql

mkdir mysql

cd mysql

...
Переглядів: 339
0

Опублікував Автор: Створено: в Uncategorized

iptables -L -n -v -x --line-number (подивитися якісь там таблички з байтами і нумераціє...)

 

iptables -N TRAFFIC_ACCT_IN (додати ланцюжок TRAFFIC_ACCT_IN)

...
Переглядів: 323
0

Опублікував Автор: Створено: в Uncategorized

http://www.catonmat.net/blog/traffic-accounting-with-iptables/

A few years ago I worked as a Linux system administrator at a small (few hundred users) Internet service provider. Among all the regular system administrator duties, I also had the privilege to write various software and tools for Linux. One of my tasks was to write a tool to record how much traffic each of the clients was using.

The network for this provider was laid out in a very simple way. The gateway to the Internet was a single Linux box, which was a router, a firewall and performed traffic shaping. Now it had to be extended to do traffic accounting as well.

...
Переглядів: 354
0

Опублікував Автор: Створено: в Uncategorized

http://www.cyberciti.biz/faq/debian-ubuntu-centos-rhel-install-apcups/

My Linux nas server connected to APC SmartUPS using usb cable and I would like to detect a power failure. If power is not restored my server must shutdown when the battery is exhausted. How do I configure and use my APC SmartUPS under Debina / Ubuntu / RHEL / CentOS / Fedora / Scientific Linux operating system for power management?


Linux comes with GPL licensed open source apcupsd server ( daemon ) that can be used for power mangement and controlling most of APC's UPS models on Linux, BSD, Unix and MS-Windows operating systems. Apcupsd works with most of APC's Smart-UPS models as well as most simple signalling models such a Back-UPS, and BackUPS-Office. During a power failure, apcupsd will inform the users about the power failure and that a shutdown may occur. If power is not restored, a system shutdown will follow when the battery is exhausted, a timeout (seconds) expires, or runtime expires based on internal APC calculations determined by power consumption rates.

...
Позначки: apc ups
Переглядів: 308
0

Опублікував Автор: Створено: в Uncategorized

маємо блок безперебійного живлення apc suA1000I

приєднали два однакових  машинних акумулятори

 Varta 6СТ-45 BLACK dynamic (B20)

...
Переглядів: 286
0

Опублікував Автор: Створено: в Uncategorized
Переглядів: 334
0

Опублікував Автор: Створено: в Uncategorized

можна подивитися на приклад чату https://github.com/socketio/socket.io/tree/master/examples/chat

але щоб недуже загубитися в двох сторінках коду є простий приклад який на ссервері пише в консоль а на браузері в консоль браузера

https://habrahabr.ru/sandbox/90655/

...
Переглядів: 359
0

Опублікував Автор: Створено: в Uncategorized

Recently, on my CentOS server, I had my system error log at /var/log/messages flooded with a whole heap of lines like the one below.


server01 atd[13653]: File a0001001567d06 is in wrong format – aborting

Naturally, this continued until the server ran out of disk space and died. I couldn’t work out how the issue actually originated however, I managed to fix the issue by deleting the at job that was failing.

The following commands fixed the problem for me.

First of all use atq to find out the job number.

# atq a0001001567d06
You should get a response similar to the one below. The first number is the job number you need to run the next command.

16 2012-09-04 00:38 a root
Using the job number from above, run atrm to remove the troublesome job

# atrm 16
Problem solved!
Переглядів: 256
0

Опублікував Автор: Створено: в Uncategorized

# node -v
v0.10.23

обновлюємо версію

sudo npm cache clean -f

...
Переглядів: 344
0

Опублікував Автор: Створено: в Uncategorized

Завдання перенаправити вхідну пошту для конкретних поштових скриньок на якийсь транспорт

наприклад на PHP скрипт

Метод 1

...
Позначки: postfix
Переглядів: 704
0

Опублікував Автор: Створено: в Uncategorized

методика звідси http://flashboot.ru/files/file/270/

1 ) взнаємо чіп \

http://disk.pp.ua/files/ChipGenius_v4_00_0022_RC3.rar

...
Переглядів: 1348
0

Опублікував Автор: Створено: в Uncategorized

можна еревірити як грузиться сайт з різних серваків

http://www.alertra.com/

Переглядів: 1249
0

Опублікував Автор: Створено: в Uncategorized

перевіряємо чи працює віртуальний інтерфейс

http://wiki.libvirt.org/page/Networking

 

...
Переглядів: 1528
0