книги хакеры / журнал хакер / 202_Optimized

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
w Click											m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
w Click											m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

/etc/shorewall/zones описывает сетевые зоны, представляет собой таблицу. Кратко расскажем про ее столбцы и приведем пример.

Столбец ZONE определяет имя зоны. Имя должно начинаться с буквы, может содержать буквы, цифры и подчеркивания и, при формате логирования по умолчанию, быть не более шести символов. Имена all, any, none, DEST и SOURCE зарезервированы. Порядок, в котором Shorewall определяет соответствие пакетов зонам, соответствует порядку определения зон. Допустимо также определение вложенных зон, но это выходит за рамки данной статьи.

Столбец TYPE определяет тип зоны и может быть одним из следующих:

•ipv4 — стандартный тип, если в данном столбце ничего не задано или стоит прочерк, то применяется по умолчанию. Соединение с некоторыми хостами зоны может быть зашифрованным.

•ipsec или ipsec4 — соединение со всеми компьютерами зоны шифровано.

•firewall — описывает собственно зону брандмауэра.

Есть еще и другие типы, но смысла рассматривать их нет.

OPTIONS, IN OPTIONS и OUT OPTIONS — определяют опции (в основном относящиеся к IPSec, например proto указывает протокол инкапсуляции) для двунаправленного, входящего и исходящего трафика соответственно.

Пример файла:

Файл /etc/shorewall/interfaces содержит описание сетевых интерфейсов, которые могут использоваться в Shorewall, и сопоставляет их с зонами. Существует два формата данного файла — со столбцом BROADCAST, используемым для предоставления интерфейсу широковещательного адреса, и без него. Формат без данного столбца задается строкой ?FORMAT 2. Перечислим вкратце доступные столбцы:

•ZONE — указывается зона, присутствующая в файле zones;

•INTERFACE — логическое имя интерфейса; каждый интерфейс может быть указан в данном файле только один раз. Виртуальные интерфейсы указывать нельзя. Допустимо использовать и символы подстановки — например, ppp+ соответствует и ppp0, и ppp5, но не ppp;

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

-x cha

• OPTIONS — список различных опций, разделенных запятыми. К примеру, опция dhcp используется чаще всего для указания того, что интерфейс получает адрес по DHCP, а опция net предоставляет возможность ограничить список подсетей для конкретной зоны.

Пример файла interfaces:

Файл /etc/shorewall/policy определяет общие политики для соединений между зонами, если пакет или соединение не соответствует ни одному правилу. Порядок строк в этом файле имеет значение. Посмотрим, какие в этом файле столбцы:

•SOURCE — источник. Может быть именем зоны, $FW (самим брандмауэром), all и all+ — последнее значение переопределяет внутризоновую политику;

•DEST — назначение. Значения аналогичны SOURCE;

•POLICY — политика. Тут используются те самые значения, которые были указаны в файле shorewall.conf. Через двоеточие можно задать конкретное действие из списка действий /usr/share/shorewall/actions.std или макрос. Если стоит NONE, над пакетом не будет произведено никакое действие. Нужно отметить, что NONE не может использоваться, если в качестве источника/назначения указан $FW или all;

•LOG LEVEL — позволяет определить уровень логирования для соединений, соответствующих данной политике. Может быть от debug до emerg, плюс возможно указывать ULOG иди NFLOG для направления логов в соответствующий демон;

•BURST:LIMIT — позволяет задать ограничения на количество соединений за единицу времени как для адреса источника, так и для адреса назначения.

Пример:

Тут разрешаются все исходящие соединения от компьютера брандмауэра в зону net и запрещаются все соединения, приходящие из данной зоны.

Наконец, файл /etc/shorewall/rules содержит собственно правила. Этот файл делится еще и на секции. Рассмотрим их. В cекции ALL задаются правила,

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

-x cha

которые будут применяться независимо от состояния соединения для пакета. Для создания правил на пакеты с учетом состояний ESTABLISHED и RELATED предназначены секции ESTABLISHED и RELATED соответственно. В качестве действий для них допустимы лишь ACCEPT, DROP, REJECT, LOG и QUEUE. Правила для пакетов в состоянии INVALID задаются в секции с соответствующим именем. Доступные действия аналогичны тем же, что описывались чуть выше. UNTRACKED применяется для тех пакетов, чье состояние нельзя отследить. Доступные действия опять же идентичны предыдущим. В секции NEW указываются правила не только для пакетов с соответствующим состоянием. Правила, указанные в ней, применяются и для пакетов с состояниями INVALID и UNTRACKED, если они отсутствуют в нужных секциях. Также, если в файле не указана ни одна секция, подразумевается, что есть только описываемая. Имена столбцов в данном случае говорят сами за себя или аналогичны тем, что были описаны ранее, поэтому их рассматривать не будем, а приведем сразу пример:

Возможно, этот пример покажется удивительным, но на самом деле действия, указанные в нем, либо соответствуют одному из действий в файле action.std (как в случае с действием Invalid(DROP), запрещающим пакеты в состоянии Invalid), либо являются макросами, как в случае с SSH(ACCEPT) и Ping(ACCEPT), разрешающими, соответственно, SSH и Ping. Во всех правилах в данном примере в качестве источника указывается зона net, а в качестве назначения сам компьютер с брандмауэром.

Nftables

Nftables представляет собой нечто аналогичное bpf: утилита nft компилирует правила в байт-код и передает его в ядро. Это позволяет не только значитель-

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
w Click											m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

но улучшить гибкость, но и уменьшить количество кода ядра. Так, отпадает надобность в реализации расширений режима ядра для поддержки всякого вновь появляющегося протокола. В качестве же базовых «кирпичиков» выступают элементы старого доброго Netfilter, такие как хуки.

Синтаксис утилиты nft, однако, отличается от синтаксиса старых утилит и представляет собой иерархический язык, более подходящий для описания правил, нежели линейный стиль iptables. Парсер для этого языка сгенерирован с помощью BISON.

SHOREWALL НА НОУТБУКЕ

Модифицируем базовый пример для ноутбука. Для простоты предположим, что дома ноутбук подключен кабелем к локальной сети и владелец его считает эту сеть доверенной, а «на выезде» он пользуется беспроводной сетью, которая, понятно, недоверенная.

Определим зоны home и wifi, для чего в файл zones добавляем строчки:

Затем добавляем зоны в файл interfaces:

И настраиваем политики (предварительно закомментировав уже существующие):

В файле правил, опять же после комментирования существующих, записываем следующие строчки:

Проверяем, компилируем и запускаем:

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
w Click											m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

Проверка

конфигов

Компиляция правил и запуск Shorewall

Все, ноутбук защищен.

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

-x cha

ЗАКЛЮЧЕНИЕ

Shorewall остается очень мощным инструментом даже сейчас, с появлением nftables. Оно, впрочем, неудивительно, поскольку это более высокоуровневый инструмент. Конфигурировать его тоже легче, что мы и увидели из примеров. Но как Shorewall можно сравнить с языком высокого уровня, так и iptables можно сравнить с ассемблером — а, как известно, в некоторых случаях (хотя и далеко не во всех) код на ассемблере, написанный человеком, более быстрый, нежели сгенерированный машиной.

Сгенерированные Shorewall правила iptables

Shorewall будет полезен как тем, кому нужно быстро составить простенький сетевой экран, так и, напротив, тем, кому требуется супернавороченный брандмауэр с роутингом и шейпингом трафика. Также он довольно быстро развивается — совсем недавно у него вышла версия 5.0 (http://shorewall.net/ Shorewall-5.html).

Таким образом, Shorewall подходит очень большому кругу пользователей. Скорее всего, подойдет он и тебе.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

hang

e

C

E

X

-

d

F

t

D

i

r

P

NOW!

o

BUY

to

w Click

m

w

w

o

.

.c

p

g

Часть

df

n

e

-x cha

вывода

команды shorewall dump. Виден список возможностей нижнего уровня

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

SYNACK

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

	ДЕЦЕНТРАЛИЗОВАННЫЙ
	ВЕБ
	ИЗУЧАЕМ
	P2P-СИСТЕМУ
	ДИСТРИБУЦИИ	Евгений Зобнин
	КОНТЕНТА IPFS
		androidstreet.net

О кончине веба как централизованной среды говорят давно, а в последнее время заговорили еще больше. Всесторонняя слежка АНБ, экспоненциально растущие объемы трафика и, конечно же, любимые нами блокировки ресурсов сыграли свою роль. Проблема только в том, что сделать веб децентрализованным, не сломав его, невозможно, однако мы можем перейти на совершенно иную технологию, из коробки предоставляющую средства для создания веб-страниц и приложений без единой точки отказа.

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

-x cha

ВМЕСТО ВВЕДЕНИЯ

Балансировщики нагрузки, кеширование, избыточность, распределенные базы данных, обратный прокси, IaaS, CDN — все эти термины уже давно стали обыденными не только для DevOps-инженеров, но и для IT-шников, работающих в совершенно иных сферах. Сегодня крупные интернет-компании используют кластеры из десятков и сотен серверов, формирующих инфраструктуру, которая выдержит и резкие наплывы посетителей, и отказ основных серверов, а нередко и физический обрыв кабеля.

Времена конфигураций «один сервер — один веб-сайт» уже давно прошли. Однако, как и раньше, мы продолжаем использовать все те же веб-технологии, что и старик Тим Бернерс-Ли. Мы изобрели HTTP/2, но до сих пор не придумали способа отвязать сервис от единой точки входа; у нас есть огромное количество технологий оптимизации отдачи контента, но почему-то мы до сих пор страдаем от DDoS-атак; у нас есть HTML5, однако мертвые ссылки остаются одной из главных проблем веба; мы платим копейки за мегабайт трафика, но отдаем огромные суммы за то, чтобы наш сервис оставался онлайн.

Мы делаем все, что в наших силах, чтобы веб был быстрым, высокодоступным и полезным, но, кажется, становится только хуже. Кто-то может назвать это нормальным, сославшись на растущее количество пользователей сети, нагрузки, объемы и «тяжесть» контента, однако корень проблемы заключается

вущербности самого HTTP как средства для отдачи огромных объемов трафика. Он просто для этого не предназначен. Система, построенная по принципу «один провайдер — миллионы потребителей», во все времена будет страдать от всех перечисленных проблем со все большим усложнением инфраструктуры провайдера, постоянно возрастающими расходами на ее содержание и опасениями, что в любой момент придет Роскомнадзор и выключит доступ к сервису одним нажатием кнопки.

Впервые это осознали создатели первых P2P-сетей и предложили совершенно иной способ распространения контента. Идея была проста как сапог: вместо того чтобы складировать все данные в одном месте, задачу их хранения и распространения возложили на самих потребителей, превратив их

вполноправных участников раздачи контента. Как мы все знаем, технология не просто взлетела, а стала одним из столпов, на которых держится современный интернет.

Можно ли применить тот же принцип для построения сайтов? В каком-то смысле да, и именно этим занимаются разработчики IPFS.

ВЕБ 3.0

IPFS (InterPlanetary File System) — это стек протоколов и технологий, позволяющий создать нечто вроде глобальной распределенной файловой системы, построенной по принципу P2P-сети. В такой сети все ноды равны и могут вы-