Несколько дней назад передо мной поставили задание — поднять mercurial-репозиторий на одной из локальных машин, и поставили одно условие — обязательная авторизация по SSH. Установка будет производится с использованием Mercurial Server на 64-битной серверной Убунте.

Многие сталкивались с таким явлением как DDoS атака методом HTTP флуда. Нет, это не очередной туториал по настройке nginx, хочу представить свой модуль, работающий как быстрый фильтр между ботами и бэкэндом во время L7 DDoS атаки и позволяющий отсеивать мусорные запросы.

Мне нравится современный Open Source. Нравится не как идея, а с вполне прагматической точки зрения. Фактом является то, что компания любого масштаба может использовать Open Source приложения в своей информационной системе и получить в результате кроссплатформенные, удобные и бесплатные решения практически любых проблем.

Мы прилагаем много усилий, чтобы «подружить» Рутокен ЭЦП и различные приложения Open Source. Для этой цели мы добавили поддержку российских криптоалгоритмов (ГОСТ 28147-89, ГОСТ Р 34-11.94 и ГОСТ Р 34-10.2001) и устройств Рутокен и Рутокен ЭЦП в проект OpenSC, а также разработали свою собственную кроссплатформенную библиотеку PKCS#11, работающую на операционных системах Microsoft Windows, GNU/Linux, Mac OS X, FreeBSD и др.

Попробовал весьма интересный стартап сервис по приему платежей пластиковыми картами stripe, основанный в Сан-Франциско.



Судя по их блогу, открылись они совсем недавно, если верить информации в интернете, в декабре 2011 года. Примечательно, что среди инвесторов данного сервиса три наиболее влиятельных венчурных фонда силиконовой долины (Sequoia Capital, Y Combinator и Andreessen Horowitz), а также Peter Thiel и Elon Musk, которые являются основателями PayPal. Такая компания инвесторов сразу привлекает внимание к проекту.

В предыдущей статье я рассказывал про фильтр U32. В этой статье речь пойдёт о так называемых tc actions — действиях, которые можно производить над трафиком. Например, можно построить файерволл без использования iptables/netfilter, или изменять отдельные байты в пакетах, перенаправлять/зеркалировать трафик на другие интерфейсы. Осваивать это будем на примерах. Продолжение под катом.

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

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

Рассмотрим защиту Windows-приложений, разработанных с использованием компилируемых языков программирования (C, C++, Pascal, Delphi, Fortran и т.д.).

В статье описываются недостатки существующей структуры DNS, полный процесс внедрения DNSSEC на примере доменов .com и .org, процедура создания валидного самоподписанного SSL-сертификата подписанного с помощью DNSSEC.

Подавляющее большинство из нас использует такое крайне полезное устройство, как источник бесперебойного питания. Качество питания не везде идеальное, да и просто мельчайшие проблемы с электропитанием иногда могут дорогого стоить. Потери данных это всегда неприятно, а иногда просто таки фатально. Устройство куплено, установлено под стол, подключено и владелец его находится в полной уверенности, что в любом случае при перебое в электропитании он успеет корректно завершить работу, а может быть и сделать бэкап на флешку. Время идет, бесперебойник периодически дает о себе знать — как заправский сторожевой пес он подает голос при малейших отклонениях в параметрах электросети. Хозяин спокоен и все хорошо. Но в один из дней перебой таки случается и в этот раз ИБП не просто подает голос и сразу переключается с батареи на сеть, в этот раз свет выключили на долго. Мы спокойно копируем файлы (ведь в запасе у нас минут 15, не меньше) и тут бесперебойник начинает пищать совсем часто и все выключается. Как так? Ведь бесперебойник же должен был нас защитить от подобных ситуаций, а он только вселял нам ложную уверенность в нашей безопасности! Почему так произошло?

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

Есть в моем ведении несколько VPSов, на которых крутится… вообщем не моя зона ответственности, и потому крутится там то что крутится, в меру тормозит, в меру работает. И оказалось, что крутится на одном из них некий форум, и начал форум притормаживать. И захотелось разобраться…

Скорость работы вашего сайта, его стабильность и отказоустойчивость всегда зависят от трех составляющих:

1. Платформа (CMS) и ее настройки, которые влияют на производительность (параметры кэширования и т.п.)
2. Конфигурация сервера (реального физического или виртуального) и настройки системного ПО (веб-сервер, база данных и т.д.)
3. Качество разработки, кода, интеграции с платформой.

Зачастую веб-разработчик может написать хороший качественный код, но при этом мало что смыслит в системном администрировании и настройке серверов. А хороший сисадмин редко бывает по совместительству еще и классным программистом.

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

В итоге сайт может «хромать» из-за проблем и «узких» мест в любой из составляющих: CMS, хостинг, разработка. Клиент в нюансы не вникает и остается не удовлетворен проектом в целом. Его негатив переносится на всех: «Тормозной хостинг! Ужасная система! Разработчики ничего не умеют!»

Такая картина нас, конечно, никогда не устраивала. И мы решили, что надо что-то делать…

Приветствую. Сегодня я хотел бы поговорить о такой неприятной ситуации, как отказ мастера в случае применения нативной репликации в PostgreSQL 9.x. Итак, предположим, что у вас есть кластер из двух и более PostgreSQL-серверов и на мастер внезапно упал метеорит. Логично предположить, что вам придётся сделать мастером одну из реплик. Сделать это можно двумя способами.

Задача

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

В статье для этой цели будут использованы Debian Linux, протокол CARP и утилита ucarp.

Введение

Внедрение электронной подписи (без разделения на используемые криптоалгоритмы и критерий «квалифицированности», см. закон 63-ФЗ, ст. 5) в информационную систему обычно вызвано необходимостью контроля целостности и авторства порождаемых в системе информационных потоков и документов.

Под катом описаны интерфейсы для работы с электронной подписью, а также распространенные форматы электронной подписи.

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

1. Увеличьте первоначальный размер congestion window до 10 (IW10). Сейчас в начале TCP-соединения отправляется три пакета данных в три раунда (RTT) для передачи небольшой информации (15 КБ). Наши эксперименты показывают, что IW10 уменьшает сетевую задержку для веб-соединений более чем на 10%.

2. Уменьшите первоначальный таймаут с 3 секунд до 1 секунды. RTT в 3 секунды был приемлем пару десятилетий назад, но в современном интернете нужен гораздо меньший таймаут. Наше обоснование для этого хорошо задокументировано здесь.

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

Итак, вводные данные. Наш сервер, судя по кривой посещаемости, в скором времени начнёт испытывать весьма суровые нагрузки, особенно в пиковые моменты. Для эффективной обработки трафика, а также во избежание отказов в обслуживании было решено использовать механизмы, предоставляемые Amazon, позволяющие в реальном времени запускать необходимое количество серверов. При этом, когда нагрузка спадает, получившийся пул должен «сбавлять обороты», автоматически уменьшаясь в размерах, и тем самым уменьшать финансовые затраты на проект.

В этой статье я расскажу о трех типах instances в Amazon с примерами подсчета стоимости и скринами с консоли и биллинга Amazon. Статья родилась в силу малого количества информации про amazon web services, в частности данных про экономию оплаты на reserved instances я не нашел в рунете. Много скринов для лучшего понимания, когда я начинал работать с amazon мне этого сильно не хватало.

В последнее время я довольно часто натыкаюсь на данную теорему. Она довольно давно доказана и про нее много чего написано. Однако каждый раз когда я натыкаюсь на распределенную систему, претендующую в описании на CA в терминах данной теоремы, т.е. систему в которой жертвуют Partition Tolerance в угоду Consistency и Avalability, я зависаю, так как хоть убейте не могу себе представить такого зверя. После долгих раздумий я все же пришел к выводу, что такая система бессмысленна, о чем и хочу порассуждать в данном топике.

Прошедшим и будущим выборам посвящается.

После вбросов, скандалов, интриг, расследований, которые были на думских выборах, невольно задаешься вопросом: а как сделать так, чтобы было все честно? Ну а применительно к ИТ, как сделать так, чтобы все было честно, да еще и с помощью высоких технологий? Я читал и про пробивание дырочек, и про QR-коды, поэтому решил внести скромную математическую лепту.
В этом топике мы поговорим с вами о том, как решить две взаимно противоположные проблемы с помощью криптографии: проблему верификации избирателя и проблему тайны голосования. Я немного расскажу о так называемой «слепой подписи» и даже представлю демонстрационное приложение, которое показывает, каким образом могут быть решены задачи верификации и анонимности одновременно, причем на основе криптоалгоритмов ГОСТ 34.10 и 34.11, которые официально одобрены ФСБ.

Приветствую.
Хочу рассказать, чем я баловался в свободное от работы в Qualys время. Так как в англоязычном интернете на удивление много шума про Slow Read DoS attack, и уверен что получу здесь много полезной критики и дельных предложений.

В августе 2011 года написал програмку slowhttptest, которая тестирует веб-серверы на наличие уязвимостей, связанных с обработкой медленных HTTP запросов, таких как slowloris и slow HTTP Post. Цель — создать конфигурируемый инструмент, облегчающий работу разработчиков и позволить им концентрироваться на создании эффективных защит, а не ковырянии в питоне, на котором написаны большинство proof-of-concept эксплоитов.

А потом решил попробовать, как реагируют серверы на медленное чтение клиентами HTTP респонсов. На удивление плохо реагируют. Дефолтные apache, nginx, lightpd, IIS отказывают в обслуживании на ура.

А суть такова:

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

Боевая задача.

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

• Виртуальный сервер в формате micro на основе Linux с доступом по SSH.
• 30Гб места в Elastic Block Storage плюс 1Гб под бэкапы.
• 15 Гб трафика в месяц.
• Выделенный внешний IP адрес.

Причем все это при желании можно зарегистрировать и подготовить к работе за полчаса, но понадобится кредитная карта, которую примет Amazon (и снимет 2 доллара) и сотовый телефон под рукой (домашний не подойдет).