Это история о том, как я соединил 5 Low-severity багов в один большой баг, с помощью которого можно было читать/писать в приватные репы на Гитхабе (опять).

Несколько дней назад гитхаб запустил баунти программу. За 4 часа я смастерил такой URL после посещения которого я получал доступ к вашему гитхаб аккаунту и репозиториям. Хотите узнать как?

Представьте себе ситуацию: неподалеку от вас случилось землетрясение, наводнение, извержение вулкана. Вы — участник OpenStreetMap, естественно, написали об этом на форуме. Следующие полдня и ночь вы вместе с другими осмерами провели за рисованием домиков, простановкой адресов, разметкой зоны разрушений и в итоге утром у вас есть подробная электронная карта района. Через полчаса за вами заедет друг и вы вместе собираетесь отвезти теплые вещи и воду пострадавшим. Как за эти полчаса — час распечатать карту, и зачем вообще пострадавшим могут понадобиться карты,

“А я… карбюратор промываю!”
Анекдот

Введение

В детском садике мы с единомышленниками препарировали кузнечиков в надежде разобраться в их строении. В школе распаивали радиоприёмник “Россия”. В институте дошла очередь до автомобилей, гайки которых были многократно переставлены. Интересы поменялись, но желание “разбирать” иногда просыпается, и сегодня оно направлено на Андроид.

Сколько раз вас выручало наличие исходников Андроида? Меня — уже не счесть. Андроид — открытый проект, но, к сожалению, у нас есть возможность только читать; править код Андроида, не будучи сотрудником Google, практически невозможно. Погрустим над этим моментом и загрузим репозиторий. Как это сделать, отлично описано на официальном сайте.

Давайте каждый попробует ответить на вопрос: как установить apache на сервер? Этот вопрос порождает ещё десяток: какая ОС стоит на сервере, какую версию ставить, где лежат конфиги по-умолчанию и т.д. и т.п.

А теперь давайте попробуем ответить на вопрос: как установить apache на 1000 серверов? Тут, при стандартном подходе, вопросов возникнет ровно в 1000 раз больше. Часть из вас наверняка подумали, что можно написать скрипт на shell/perl/python/ruby, который будет обходить все сервера и устанавливать apache, другая часть подумала о distributed shell'ах (PDsh, dsh, etc), кто-то же подумал монтировать rootfs серверов по NFS.

В ряде случаев выше предложенные варианты решений удовлетворительны, но на практике я нигде не видел полностью гомогенных систем (зачастую, внутри компании можно встретить не только разные версии ОС, но и различные дистрибутивы. Также в России/СНГ очень распространена каша из FreeBSD/Linux в ядре проектов), так что вряд ли за адекватное время будет возможно написать скрипт, который установит и настроит apache на зоопарке в 1000 машин под CentOS, Debian, Ubuntu, FreeBSD всевозможных версий.

По моим наблюдениям, очень мало IT подразделений, даже очень крупных компаниий, используют в своей работе SCM (Software Configuration Management). В этом посте я постараюсь описать все преимущества использования Chef в IT инфраструктуре на простых примерах и больших масштабах.

Если же, после столь короткого вступления, вы не прониклись идеей Chef, да и времени читать длинный технический пост у вас нет, то рекомендую вам пролистать до конца и посмотреть как используем Chef мы, Engine Yard, 37signals и подумать, можете ли вы переложить на него часть своей работы.

Иногда необходимо прописать DNS для компьютера с динамическим IP адресом. Простым путем для этого являются сервисы по типу dyndns, описанные в недавнем топике Связываем домен и динамический IP. Иногда такой подход работает достаточно плохо.

Напрмер в моей ситуации, провайдер иногда меняет мой публичный IP адрес. Это иногда случается обычно раз в несколько месяцев. Кроме того, мой домашний компьютер перезагружается крайне редко. За это время сервис dyndns, которым я пользовался ранее успевал пару раз прислать мне оповещения о неактивности с целью отключить «неиспользуемый» аккаунт. Перейти на вручную прописываемую DNS зону также не получается, потому что иногда адрес все же меняется. Причем обычно об этом узнаешь когда нужен доступ к домашнему компьютеру здесь и сейчас.

Для реализации описываемого метода понадобится сервер в интернете с DNS сервером bind на нем. А так же доменная зона, субдомен которой мы будем выделять для нашего компьютера. Описывается вариант с подключением Linux-компьютера к Linux-серверу. Для использования других операционных систем понадобится почитать мануалы и модифицировать некоторые шаги.

Почитав недавние топики про DynDNS решил написать краткую инструкцию по связке DHCP с DNS.

В любой локалке рано или поздно появляется необходимость прописывать прямую и обратную зону. Можно конечно указать в обратной зоне запись вида:
$GENERATE 0-255 $ PTR pptp-$.isp.net.
Но это не выход, более красиво будет выглядеть запись вида %username%.isp.net.
В принципе с любого биллинга можно генерировать конфиги для dhcp, этот шаг упустим, перейдем к сути.

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

IAdmin — это система создана для автоматической генерации конфигов Bind на хостинговом сервере и представляет собой базу iadmin в БД MySQL и скрипт, который на основании данных из базы генерирует конфигурационные файлы. Для настройки Bind используются таблицы dns_domains, dns_records, dns_subgmail. Основной скрипт, написанный на перле читает данные из БД iadmin и создаёт файлы конфигурации. Файлы зоны генерируются в дирректории /var/cache/bind/. Там же хранятся и прочие файлы зон, которые не обслуживаются системой iadmin. Этой же системой создаётся конфиг для secondary-DNS, который туда и переносится. До тех пор, пока скрипт не отработает, все изменения из БД НЕ материализуются.

В далеком 2007 году, когда Ukrnames был еще маленьким и делал первые шаги, большую часть работы выполняли программисты. Они и разрабатывали систему управления доменами, и тестировали ее, и администрировали сервера, где все это добро работало.

А там где домены, там DNS. А какой самый простой способ сделать DNS-сервер? Поставить вездесущий BIND. Да BIND непростой, а с DLZ патчем, чтобы с MySQL дружил.

Шли годы, система работала, мощности серверов росли. А как водится, пока работает – не трогай. Так бы это все и продолжалось, если бы нагрузка не начала упираться в очередной 8-ми ядерный сервер.

В этот момент пришлось принять волевое решение и построить новую систему DNS-серверов, вместо того чтобы в очередной раз апгрейдить железо для ненасытного BIND+DLZ.

И тут закончилась сказка, и начались суровые будни администратора.

В старые добрые времена наш проект неоднократно подвергался DDoS атакам разного типа, разной мощности и продолжительности. Мы отработали много разных методов защиты, а также оптимизировали саму структуру сервиса, частично в аспекте хостинга и расположения серверов. Важной частью выученного урока была правильная настройка DNS. Как показала последняя атака на Хабр и комментарии о проблемах, аналогичным нашим, не все уделяют защите DNS должного внимания, а очень и очень зря.

С каждым годом скорость интернета — как последней мили, так и магистральных каналов становится все выше. Лишь одно неизменно — латентность уже уперлась в физические ограничения: скорость света в оптоволокне — около 200тыс километров в секунду, и соответственно, быстрее чем за ~150ms ответ от сервера через атлантический океан не получить в обозримой перспективе (хотя конечно есть изыски, вроде оптоволокна с воздушной сердцевиной или радиорелейной связи, но это для простых смертных едва-ли доступно).

Когда мы пытаемся например из России открыть web-сайт, расположенный в США (его NS сервера вероятно там же), и домен не нашелся в DNS-кэше вашего провайдера — то ждать придется долго даже на гигабитном интернете, возможно даже целую секунду: пока мы через океан получим имена NS серверов домена, пока разрезолвим их IP, пока отправим и получим собственно сам DNS запрос…

Пару лет назад Google завела свои публичные DNS сервера, а для агитации перехода на них — они разработали утилитку NameBench, которая прогоняет тесты DNS по вашей истории серфинга и показывает, насколько Google DNS быстрее DNS сервера вашего провайдера.

Но мне удалось сделать свой DNS сервер, который работает быстрее Google Public DNS, и в этой краткой заметке хочу поделится результатами.

У Вас может быть идеально настроено конечное сетевое оборудование, полный порядок в кластерах, могут быть пустыми магистрали и не нагруженное оборудование ядра сети, но если у Вас плохо работает DNS, то Ваши клиенты будут недовольны.

Отсюда следует простой вывод — Ваши рекурсивные DNS сервера должны быть всегда доступны и в состоянии обслужить запросы клиента.

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

Есть:
— отключенный за неуплату интернет (adsl, lan, etc)
или
— нешифрованная wi-fi сеть c закрытым интернетом, но работающим dns
или
— очень строгий firewall с открытым dns

Хочется:
полноценный интернет, пусть даже очень медленно

Дано: полное отсутствие интернета и виднеющийся WiFi hot-spot, в котором предлагают ввести логин-пароль. Или 3G, в котором нет интернета (потому что закончились деньги), но есть страничка провайдера с предложением дать оных денег.
Задача: получить интернет (легальным?) методом посредством туннелирования его через DNS.
Решение: linux+ iodine + routing + NAT + squid, и всё это под управлением network manager'а.
В статье: описание организации DNS туннеля посредсредством программы iodine, нюансы организации маршрутизации через образовавшийся туннель, самописный помощник для iodine и network manager.

Лирика: Занесла меня судьба на славный остров Кипр, кой славен своим П/пафосом, фраппэ и таким интернетом, после которого российские опсосы начинают выглядеть ангелами во плоти. В частности, попытка подключиться к интернетам закончилась ожиданием, что местный провайдер (Сyta) смилостивится, таки закончит пить оный фраппэ и дотянет до меня поганый ADSL 4Мб/768кбит всего-навсего за €151 (подключение) + €40 в месяц (за 4 мегабита! >_<). Ожидание тянулось и тянулось (как бы уже третья неделя пошла), а рядом был славный PrimeTel, который предлагал за €4/час (172р/час) осчастливить меня интернетом прямо тут и сейчас через едва видный WiFi. Я бы даже и согласился, но видна точка доступа была только на балконе, а в квартире связь была нестабильной и часто терялась. Так что оставалось одно решение (помимо взлома WEP-сети соседей, что уж совсем уголовщина) — это злоупотребить сервисом DNS, который безвозмездно, то есть даром, предоставляет PrimeTel для своих незарегистрировавшихся подлюченцев.

Те, кому интересно «howto» — решение далее по тексту, а пока что начнём с теории процесса.

Среди документов опубликованных Эдвардом Сноуденом, бывшим сотрудником ЦРУ и Агентства национальной безопасности США, были обнаружены материалы описывающие некоторые детали технологий шпионажа используемых АНБ. Список программных и аппаратных средств оформлен в виде небольшого каталога. Всего сорок восемь страниц отмеченных грифами «Секретно» и «Совершенно секретно», на которых дано краткое описание той или иной технологии для слежки. Данный список не является исчерпывающим. Представлены техники связанные с получением скрытого доступа к вычислительной технике и сетям, а также способы и устройства радиоэлектронной разведки связанные с мобильной связью и оборудование для наблюдения. В этой статье я расскажу об этих методах шпионажа, далее будет четыре дюжины слайдов(осторожно, трафик).

На конференции SIGGRAPH ASIA 2013 Thomas Geijtenbeek, Michiel van de Panne и Frank van der Stappen представили метод симуляции физики двуногих существ на основе мускульного контроля с оптимизацией перемещения мышц и других контролируемых параметров. В результате был получен метод управления передвижением для множества двуногих существ. Все приводящие в действие силы являются результатом работы симулированных 3D-мускул и модели нейронных задержек, включенных в цепи ответных реакций. Перечисленные контроллеры генерируют вращающие движения, которые учитывают биомеханические ограничения. Контроллеры находят различные походки на основе требуемой скорости, могут учитывать неровные поверхности и внешние возмущения, способны следовать в задаваемом направлении.

Сайт devdocs.io — проект французского программиста Тибо Курубля. Здесь собрана и упорядочена документация по наиболее популярным веб-технологиям, фреймворкам и API, и многим другим средствам разработки. DOM, HTML, JavaScript, jQuery, Node.js, PHP, Ruby, Python, Git, Angular, Backbone, CoffeScript, Less, Sass, Redis и много чего ещё… Всё оформлено в едином стиле, по всей базе документации работает поиск, в том числе нечёткий. Есть возможность выбрать только необходимые технологии, по которым надо искать. Вообще, интерфейс DevDocs радует — ничего лишнего, всё очень понятно и функционально, доступно множество клавиатурных сокращений.

Привет %username%! У нас отличные новости: вышла официальная версия NinjaMock — онлайн-сервиса для создания прототипов. Теперь ты можешь рисовать отличные прототипы веб- и мобильных приложений совершенно бесплатно!

На выставке SIGGRAPH ASIA 2013 (англ.), посвященной компьютерной графике и интерактивным технологиям, представлена разработка 3–Sweep, позволяющая лишь по одной фотографии получить трехмерный объект с текстурой. Хотя речь идет о объектах являющихся наборами примитивов и их растяжений по некоторому пути, но скорость и простота работы впечатляет! Также оценивается и дополняется то, что могло бы быть за объектом, после его вырезания из фотографии, хотя мы уже видели похожий инструмент от Adobe.

1. Фильтры отображения

Анализаторы трафика являются полезным и эффективным инструментом в жизни администратора сети, они позволяют «увидеть» то что на самом деле передается в сети, чем упрощают диагностику разнообразных проблем или же изучение принципов работы тех или иных протоколов и технологий.
Однако в сети зачастую передается достаточно много разнообразных блоков данных, и если заставить вывести на экран все, что проходит через сетевой интерфейс, выделить то, что действительно необходимо, бывает проблематично.
Для решения этой проблемы в анализаторах трафика реализованы фильтры, которые разделены на два типа: фильтры захвата и фильтры отображения. В прошлый раз мы рассматривали фильтры захвата. Сегодня пойдет речь о втором типе фильтров – о фильтрах отображения.
Фильтры отображения, это разновидность фильтров, позволяющая отобразить только те кадры, которые необходимы в данный момент (принадлежат определенному протоколу и/или узлу), временно скрыв все остальные.
Правила написания фильтров отображения отличаются от правил написания фильтров захвата. Отличая не такие уж большие, но как правило достаточные для того что бы правило фильтра захвата без каких-либо изменений не работало будучи примененным как фильтр отображения.