вторник, 19 августа 2014 г.

Squid: Tor + Privoxy + transparent DNS redirect. Часть II

Как мы это делаем? Всегда правой!


Введение

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

Суть предложенной комплексной методики заключается в залповом решении проблем обхода всех известных видов блокировок даже при их одновременном разнобойном применении. С сохранением полной невидимости для провайдера - МарсТелекома - и сохранением части трафика открытым. Дабы не смущать марсиан.

Как и в случае автомата Калашникова, составные части известны. Я всего лишь собрал их в кучу и заставил относительно эффективно и прозрачно работать. ;)

С некоторой степенью уверенности можно говорить, что заблокировать такой доступ можно лишь полным отключением Интернета для использующей методологию сети.

Я еще раз подчеркиваю - гарантированный пробой блокировок МарсТелекома обеспечивается лишь при выполнении всех частей методологии. 

Обеспечение чистого DNS

Нам необходимо обеспечить чистый источник DNS-ответов: избегать широко известных публичных сервисов, которые легко прозрачным образом перехватить, использования корневых серверов, общеизвестных стандартных (и легко перехватываемых) портов.

Мы предполагаем, что у вас уже есть сервер с работающим Squid, Unbound и dnscrypt. Читать здесь, здесь и здесь.

Итак, у нас есть настроенный Squid, Unbound и dnscrypt.

Нам надо немного скорректировать конфигурации для обеспечения максимальной безопасности получения DNS-данных.

dnscrypt

Вам потребуется последний dnscrypt. Он содержит CSV-список провайдеров, поддерживающих шифрованный доступ.

Изменим конфигурацию. 

Надо отказаться от использования OpenDNS - его адреса и порты безопасного доступа известны.

Первое. Выберем в качестве провайдера dnscrypt.eu-dk, например. Из списка $BASE_DIR/share/dnscrypt-proxy/dnscrypt-resolvers.csv . 
Второе. Во избежание прозрачного перехвата UDP/53, пожертвуем производительностью (у нас все равно позади dnscrypt стоит кэш DNS) и будем использовать только TCP (ключ --tcp-only у dnscrypt).

Перезапустим сервис. Убедимся, что мы получаем DNS-ресловинг от выбранного сервиса.

Unbound

Unbound требует некоторой модификации в конфигурации. 

Первое. Необходимо исключить обращение к корневым DNS. Закомментируйте параметр root-hints: "/etc/opt/csw/unbound/named.root"
Второе. Уберите любые ссылки на открытые (и уязвимые) форвардеры:

forward-zone:
name: "."
forward-addr: 127.0.0.1@5553

У вас должна остаться единственная ссылка на dnscrypt.

Перезапустите Unbound и убедитесь, что кэш пуст.

ВАЖНО
Учтите следующее. Перед вашим транспарентным прокси наверняка стоит маршрутизатор, или switch L3, выдающий динамикой адреса, шлюз и DNS. Однако стоит учитывать тот факт, что, во-первых, у вас есть не только динамические клиенты, но и те, которые прописали параметры TCP вручную. А во-вторых, прокси у вас прозрачный - но есть и другие клиенты - не-HTTP - которым тоже нужен чистый DNS для работы - Google Drive, IRC, итп., которые могут идти мимо транспарентного прокси.

Поэтому проделаем на внутреннем роутере (который форвардит HTTP на прокси по WCCP) транспарентный перехват всех вообще DNS-запросов нашей собственной сети (Cisco):

ip access-list extended transparent_dns
permit udp any any eq 53
!
route-map redirect_dns permit 10
match ip address transparent_dns
set ip next-hop ip.of.your.server
route-map redirect_dns permit 20
!
interface fax/x
ip address xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
ip policy route-map redirect_dns
!

Как видно из примера, мы будем переотправлять все вообще запросы с Cisco DNS proxy только на наш собственный кэш, где уже стоит Unbound+dnscrypt. Так надо.

Да, это та же самая методика, что и у МарсТелекома. ;) Только с противоположной целью. :)

Tor + Privoxy

Небольшое пояснение, на кой ляд нужна именно такая связка. 

Дело в том, что Tor- не HTTP-прокси. И его нельзя сделать прямым peer для нижележащего (и кэширующего) Squid'а. Он предоставляет лишь SOCKS-проксирование (разумеется, в числе прочих функций).

Tor
Первое, конечно же, Tor. В принципе, вы можете настроить его как угодно - только как клиент, как бридж, как релэй. Достаточно одной клиентской конфигурации. Но если вы имеете постоянное (и достаточно скоростное) подключение - лучше релэй или бридж. ВАЖНО: Не делайте его выходной нодой. Так меньше шансов, что МарсТелеком возьмет вас за задницу и/или забанит IP (особенно в случае статики). Кстати, примите как данность, что выходные ноды и так весьма часто попадают под бан - на сервисах в том числе. Вопросы производительности тоже немаловажны (вы же через туннель будете качать приличный объем, поэтому либо не включайте аккаунтинг Tor вообще - либо задайте его достаточно высокой дневной величиной - согласно вашей собственной статистике), поэтому позаботьтесь о резервировании достаточной полосы пропускания в конфигурации собственно Tor (в идеале не менее полной максимальной полосы пропускания вашего канала - так задержки при прогрузке сведутся к минимуму).

Приведу собственную конфигурацию (Имя ноды, по понятным причинам, изменено ;)):

SocksPort 9050
Log notice file /var/log/tor.log

RunAsDaemon 1
CookieAuthentication 1

ORPort 9001

Nickname FuckYouMan

RelayBandwidthRate 400 KB #
RelayBandwidthBurst 800 KB #

AccountingMax 100 GB
AccountingStart day 00:00
# NOTE: Monitoring statistics can not get if accounting not configured

## Uncomment this if you run more than one Tor relay, and add the identity
## key fingerprint of each Tor relay you control, even if they're on
## different networks. You declare it here so Tor clients can avoid
## using more than one of your relays in a single circuit. See
## https://www.torproject.org/docs/faq#MultipleRelays
## However, you should never include a bridge's fingerprint here, as it would
## break its concealability and potentionally reveal its IP/TCP address.
#MyFamily $keyid,$keyid,...

#ExitPolicy accept *:6660-6667,reject *:* # allow irc ports but no more
#ExitPolicy accept *:119 # accept nntp as well as default exit policy
ExitPolicy reject *:* # no exits allowed

Обратите внимание - мы сконфигурировали SOCKS-вход со стандартным портом в сеть Tor, доступный (по умолчанию) только с localhost. Если хотите торифицировать другие сервисы в локальной сети, укажите также адекватный ACL (не откуда хочешь! а то подарите анонимный SOCKS-прокси хакерскому сообществу) для, скажем, 192.168.0.0/16.

Privoxy
Теперь (мы не можем прямо перенаправить наш Squid на Tor, помните?) надо установить и сконфигурировать Privoxy. Последняя версия Privoxy берется на http://www.privoxy.org, конфигурируется хитрым образом, и собирается в нужной разрядности:


0. groupadd privoxy
useradd -g privoxy -c "privoxy_daemon" -d /var/empty -s /bin/false privoxy

1. make && make clean

2.
# 32 bit GCC
./configure --prefix=/usr/local/privoxy --enable-large-file-support --with-user=privoxy --with-group=privoxy --disable-force --disable-editor --disable-toggle 'CFLAGS=-O3 -m32 -mtune=core2 -pipe'

# 64 bit GCC
./configure --prefix=/usr/local/privoxy --with-user=privoxy --with-group=privoxy --disable-force --disable-editor --disable-toggle 'CFLAGS=-O3 -m64 -mtune=core2 -pipe' 'LDFLAGS=-m64'

3.
gmake
gmake install-strip


Учтите, что для Solaris придется написать SMF-сервис. Или взять мой.

Конфигурация Privoxy (показаны только те параметры, которые реально требуется менять/задавать):

listen-address 127.0.0.1:8118
toggle 0
enable-remote-toggle 0
enable-remote-http-toggle 0
enable-edit-actions 0
forward-socks5t / localhost:9050 .
max-client-connections 4096


Точка в строке forward-socks5t - не опечатка!

В зависимости от нагрузки на туннель, может потребоваться скорректировать значение max-client-connections.

Запустим Privoxy. Убедимся, что сервис работает и слушает порт 8118. Итак, мы нацелили его на наш SOCKS5-вход Tor и слушаем HTTP/HTTPS запросы на порту 8118. Ролью Privoxy будет трансляция HTTP(S) в SOCKS5t. Напоминаю, что Privoxy - не кэширующий прокси! Кэшированием у нас будет заниматься Squid.

Squid

Итак, у нас уже есть настроенный транспарентный Squid с качественным кэшированием (ну и сохранением в дисковом кэше роликов Ютуба, в идеале ;)). Осталось доделать совсем немного.

Небольшое пояснение. Мы будем торифицировать только некоторые URL, остальной трафик будем выпускать как есть (ну, через Squid, разумеется). Регулярные выражения редиректов поместим в отдельный текстовый файл. И - так как мы будем видеть входы в туннель из внутренней сети, для защиты нас и наших пользователей, запретим журналировать доступы к Tor-сети (остальные доступы так и будут писаться в access log). Нам же дорога их и наша приватность, верно? ;)

Вот что нужно добавить в конфигурацию Squid:

# Tor acl
acl tor_url dstdom_regex -i "/usr/local/squid/etc/url.tor"

# Privoxy+Tor access rules
never_direct allow tor_url

# Local Privoxy is cache parent
cache_peer 127.0.0.1 parent 8118 0 no-query no-digest default

cache_peer_access 127.0.0.1 allow tor_url
cache_peer_access 127.0.0.1 deny all

# We don't log tor tunnel access - Squid 2.x rule
log_access deny tor_url


# For Squid 3.x log_access is deprecated:
access_log daemon:/data/cache/log/access.log buffer-size=128KB !tor_url

Файл /usr/local/squid/etc/url.tor содержит регулярные выражения dstdom_regex, по которым мы будем выборочно заворачивать в туннель Tor заданные URL:

livejournal\.com.*
youtube.*
ytimg.*
googlevideo.*
google.*
googleapis.*
googleusercontent.*
gstatic.*
gmodules.*
blogger.*
blogspot.*

Дополнить список согласно своему желанию. :)

Перезапускаем Squid, проверяем - вуаля.

Заключение

Обратите внимание на следующее.

Соединение видите только вы, до точки входа в туннель, причем отключив журналирование конкретно редиректного ACL вы (и Те, Кому Надо) перестаете их видеть. Только прямой трафик кэширующего прокси. Дальше, начиная с вашей точки доступа, никто ничего не видит - ни DNS-запросов, ни туннелированного трафика. Просто шифрованные сессии.

Что со скоростью?

После некоторого прогрева кэширующего Squid (и, при необходимости, подстройки параметров производительности промежуточных звеньев)  вы получаете весьма приличную производительность (во всяком случае, выше, чем у Tor Browser) и нормальный стриминг онлайн-видео.

Почему МарсТелеком может не напрягаться по поводу данного решения? (а он может не напрягаться)

Потому, что среднестатистический хомяк всего этого ниасилит. :) Никогда. :)

Он скорее потащится на Яндекс, давиться мусором, рекламой ну и сорить на всех углах своей приватностью и правом свободы выбора.  :)

понедельник, 18 августа 2014 г.

Squid: Tor + Privoxy + transparent DNS redirect. Часть I

"Ничего на свете лучше не-ету
Чем смотреть Ютуб по белу свету
Телекома ласковые сво-оды
Не заменят никогда свобо-оды!
Не заме-енят ни-ког-да сво-бо-оды!

Ничего на свете лучше не-ету
Чем гуглить что надо без запре-ета
Пусть на яндекс бегают приду-урки
Нам по нраву дудлы по наку-урке,
На-а-ам по нра-аву дудлы по наку-урке!"
(Бременские музыканты)


Не говорите мне, что мне сёрфить - и я не скажу, куда вам пойти.
(перефразированная поговорка)

Лично я ничего не имею против того, что МарсГлавНадзор чего-то там блокирует. Мне дела нет до всяких одиозных сайтцов. Но - меня сугубо напрягает, когда блокируется половина сервисов Гугла, которые лично я использую в работе каждый день. Транслятор, драйв, глобальный портал Гугла.

Кроме того, есть еще один либеральный принципиальный вопрос.

Я взрослый человек и я желаю САМ решать, что мне вредно а что - полезно. И если я, как админ прокси, что-то разрешаю своей пастве - я не желаю, чтобы это мое подмножество разрешенного кастрировали. И остальные взрослые за моей инфраструктурой также имеют это право.

Давайте посмотрим, как можно отправить "господ" из МарсГлавНадзора в пешее эротическое путешествие. То есть сюда.

Немного теории: Как Мордор это делает


Опыт последних лет показал, что для блокирования интернет-ресурсов используется, как правило, три подхода (по отдельности или в различных комбинациях): транспарентный перехват DNS-запросов, транспарентное проксирование HTTP/HTTPS и блокировка по URL и DPI.

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

Транспарентный перехват DNS

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

Ныне данное решение практически неработоспособно.

Провайдеры используют перехват всего трафика UDP/53 как по порту, так и прямые обращения к корневым серверам (root-hints) и к широко известным публичным DNS (Google DNS, OpenDNS итп.).

Данный трафик прозрачно заворачивается на провайдерский DNS с авторитарными зонами для блокированных доменов.

Причем подобное решение практически невозможно обойти или обнаружить посредством, скажем, DNSSEC - провайдер тупо подписывает ключ своей авторитарной зоны одним из глобальных CA - и вуаля, ваш верификатор даже не гавкнет (мало кто заглянет в данные ключа зоны). В некоторых тупых случаях провайдер может тупо игнорить DNSSEC и не позволять верифицировать домены на рутах (помним? Руты перехватить легче всего, их адреса общеизвестны и редко меняются).

Прямое задание DNS-серверов, угодных лично вам, а не провайдеру - помогает плохо. Вы используете общеизвестные сервера, а Мордору они тоже известны.

Некоторые провайдеры (например, пчелайн) тупо энфорсят использование своего DNS для установления клиентского соединения. Так - и баста. С учетом того, что они в принципе лижут ж.пы правительствам стран, в которых работают - обойти это довольно сложно без промежуточного хоста и некоторых ухищрений (однако, это возможно).

Как обнаружить подмену DNS?

С определенными оговорками по части вероятности обнаружения - вот детектор.

Имейте в виду следующее. Надо правильно интерпретировать результаты теста. Вы не должны видеть посторонних с вашей точки зрения DNS-серверов (равно как и провайдерских) и видеть лишь то, что вы сами задали либо те сервера, которым доверяете.

Следует учитывать, также, тот факт, что наличие собственного DNS в вашей компании не спасает от подмены DNS. Кэширующие сервера отравляются недостоверными записями из провайдерских практически молниеносно (вы же не задаете для них максимальный TTL, верно?)

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

Поэтому одна из ключевых задач в подобной ситуации - это обеспечение стерильности вашего кэширующего DNS и наполнение его по защищенным каналам исключительно из достоверных и доверяемых источников. Практическое решение этой задачи мы рассмотрим далее.

Транспарентный провайдерский прокси

В предыдущих публикациях я наглядно показал, как легко можно построить практически невидимый транспарентный HTTP/HTTPS-прокси общедоступными средствами. 

Обнаружить наличие такого прокси для непрофессионала при соответствущей настройке - неразрешимая задача. Даже профессионал зачастую может вычислить такое устройство в инфраструктуре провайдера исключительно по косвенным признакам.

Оставив в покое коллег-крыс, реализующих подобное с любыми корыстными целями, хочу заметить, что существует масса проприетарных высокопроизводительных решений от вендоров (например, IBM - что совершенно не странно. Ничего личного - это лишь бизнес, ребята), которые массово закупаются мордорскими правительствами.

Обход подобных методов требует наличия как минимум простецких средств типа Hidemyass, FriGate (практически бесполезен в 2014м году), ZenMate (легко блокируется ввиду конечного количества и статичности выходных серверов) и тому подобных браузерок.

Почему я считаю подобные методы бесполезными?

Первое. Легко блокируются сами сайты производителя.
Второе. Элементарно вычисляются и блокируются входные точки сервисов.
Третье. Подобные решения обычно используются для защиты лишь HTTP/HTTPS и 
Четвертое. Я склонен не доверять заявлениям подобных сервисов о действительной приватности ваших данных, гуляющих внутри туннелей.

Что действительно эффективно в подобном случае?

Tor, только Tor и пока ничего кроме Torа.

Достоинства Тора:

Первое. Он имеет распределенную плавающую структуру, которую дьявольски трудно заблокировать целиком. Даже Китай не сумел забанить _все_  узлы сети. Выходные ноды банятся легко. Входной нодой может являться любой узел сети.
Второе. Он образует глухие туннели, использующие в большинстве случаев самоподписную иерархию сертификатов, чрезвычайно затрудняющую бампинг и им подобные техники.
Третье. Он часто использует нестандартные порты для роутеров, что позволяет проделывать разные трюки, затрудняющие блокировку.
Четвертое. Его концепция рассчитана на обеспечение защиты даже в случае частичной компрометации сети. Разумеется, защита не абсолютна - но для наших целей ее в данный момент достаточно.
Пятое. Доступ посредством бриджей практически невозможно заблокировать никаким образом.
Шестое. Тор позволяет обойти блокировку не только HTTP/HTTPS, но практически любых сервисов, которые можно затолкать либо в туннель, либо проксировать, либо используя SOCKS.

Безусловно, Тор не волшебная пуля - но очень мощное средство, решающее задачу чуть более, чем полностью.

Помните о смерти - выходные ноды могут прослушивать выходящий трафик в открытом виде! Шифрованные туннели Тор не отменяют необходимости шифровать чувствительные данные на всем пути от вашей станции до сервиса!

Для клиентов с минимальными навыками существуют сборки, полностью готовые к употреблению.

Хотя мы рассматриваем инфраструктурное (сиречь серверное) решение, упомянуть о конечном клиентском решении все же стоит.

К недостаткам Tor следует отнести провал в скорости в большинстве случаев практического применения, что решается единственным способом - каскадированием с кэширующими прокси-серверами. Малоэффективно в случае одной клиентской машины, достаточно эффективно в случае инфраструктурного решения.

DPI

Глубокая инспекция пакетов является наиболее мощным средством блокирования почти всего, чего пожелает обладатель рубильника.

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

Как и в предыдущем случае, Tor, благодаря своему дизайну, позволяет с различной степенью затратности обойти и проигнорировать блокирование.

Учтите следующее. У клиентов Tor (равно как и у серверов) есть характерная сигнатура при входе в сеть. Которую легко заблокировать. 

Однако (см. второй абзац данного раздела) режим бриджа спасет гигантов мысли.

Route spoofing

Еще одна мерзкая техника блокирования, целиком позаимствованная из арсенала черных шляп (впрочем, понимающий человек уже давно обратил внимание, что почти все методики - хакерские. Вам - нельзя, по закону; а им не только можно, но и нужно. В такой связи, между нами, я вообще считаю себя вправе использовать любые методы противодействия. Это не противоречит админской этике, как бы странно это ни звучало).

Методика весьма эффективна против так называемых продвинутых юзеров. Причем она довольно сложно обнаружима и труднодоказуема.

Вас средствами роутеров заворачивают на бездействующие адреса. Белые. Визуально похожие на целевые. Но молчащие.

Нет, не режут средствами ACL цисок. Не посылают TCP_RESET (помните? connection reset by peer). Вас просто роутят вместо гугла на пачку адресов, которые не используются. Например.

И не факт, что вас не логгируют.

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

Хорошо, допустим вы - продвинутый хомяк. Берете traceroute, dig, nslookup, сверяете истинные адреса (кстати, где вы их возьмете в такой ситуации? :)) и со скринами в руках рветесь к министру связи Марсианской республики.

А министр связи на голубом глазу отвечает, что на планете Марс все зашибись и это проблема на стороне сервиса Большого Сырта. :))))))))

Марсиане из Большого Сырта разводят руками и говорят, что у них все ок - на всех направлениях. Но обещают проверить еще раз.

Допустим, возмущенных хомяков много. Министр обещает дать пинка Марстелекому. Марстелеком, бия себя раздвоенным копытом в грудь, клятвенно обещает разобраться. Чуть позже, обливаясь крокодиловыми слезами, сообщает, что это-де технические проблемы с роутингом. И что скоро все будет ок. 

Но они же не обязаны бежать, расшибаясь, немедленно делать - даже если это правда, верно? Это же не 01-02-03. :)

Умная Маша в этом случае - помните слово "роутинг"? - скажет, что Tor - снова наше все - и будет совершенно права.

Conclusion

Как видите, трюки, используемые дабы тащить и не пущать - довольно продвинутые, и, мало того, совершенно грязные и хакерские.

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

В следующих частях рассмотрим в деталях, как мы это делаем.

(продолжение следует)

вторник, 5 августа 2014 г.

Solaris 10, IPMI и контроль температуры в серверной

Намедни вводили мы в строй новый сервер. 

Поскольку вешать в маленькую серверную климат-контроль было несуразно, решили для контроля температуры использовать датчики нового сервера, доступные через IPMI.

Ну и хотелось, конечно, получать уведомления о превышении температуры. Дабы вовремя заглянуть. Хотя бы на почту.

Имея в распоряжении IPMI, все сравнительно просто.

1. Настроить форвардером собственный smtp/sendmail Solaris. Как это сделать - миллион раз обсосано.

2. Написать скрипт проверки датчика температуры сервера и отсылки единственного уведомления при превышении этой самой тепрературы:

#!/bin/sh

CC="yourmail@yourdomain"
FLAG="/tmp/check_temp.alert"

alert_level=35

mes_t=`/usr/sbin/ipmitool sensor get "Peripheral Temp" | /bin/grep Reading | /bin/cut -f2 -d":" | /bin/cut -f1 -d"("`

if [ $mes_t -gt $alert_level ]; then
# echo "ALERT: Temperatire above $alert_level!"
if [ ! -f "$FLAG" ]; then
echo "`/bin/date` ALERT! Temperature above $alert_level! Server temperature is $mes_t"| /bin/mailx -s "`/bin/date` Thermal alert" -c $CC staff && echo "Temp $mes_t">$FLAG
exit 1
fi
fi

if [ -f "$FLAG" ]; then
rm "$FLAG"
fi

exit 0


3. Поставить задание в крон, вызывающее оный скрипт с некоторой периодичностью:

# Server thermal control job. Running every 15 minutes
0,15,30,45 * * * * [ -x /usr/local/bin/check_temp ] && /usr/local/bin/check_temp.sh >/dev/null 2>&1


Всего делов.