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

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

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

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

Первая часть.

Система пляжного управления компанией или автоматизированный мониторинг ключевых показателей успешности.

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

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

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

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

Первая статья посвящена tma (общий управленческий учет) — понятию, призванному возглавить все эти перемены в будущем.

Все мы, теми или иными способами уходим в облака ) На просторах интернета набрел на очень интересный и полезный сервис. Идея гениально проста. Регистрируемся, добавляем свои аккаунты (из внушительного списка облачных сервисов) и получаем к ним доступ с одного логина. “Ну и что” скажете Вы. Не торопитесь, теперь самое интересное. Этот сервис позволяет натурально настроить WebDAV доступ ко всему Вашему богатству! Интересно? Прошу под кат…

Не так давно совместно с компанией InNetMedia в рамках Хабра был опубликован перевод инфографики на тему "7 способов увеличения лояльной аудитории".

Сегодня вашему вниманию предлагаем инфографику "Психология социального шоппинга". Данная инфографика разошлась за бугром тиражом почти в 400 копий и мы не смогли пройти мимо такого материала ;)

В нашей компании в качестве почтового сервера используется Zimbra Collaboration Server. И хотя при наборе адреса подходящие имена автоматически подставляются в адресное поле, однажды была поставлена задача сделать общую адресную книгу на базе GAL (global address list). Преимущество такой книги в том, что она всегда является актуальной, операции над акаунтами (удаление/добавление/редактирование) автоматически применяются к книге и отображаются у всех пользователей. В принципе задача не сложная, но как оказалось несколько заковыристая. Поэтому я опишу весь процесс, дабы помочь тем, кто столкнется с подобным. А также приведу примеры исправления возможных ошибок.

Описание касается Zimbra Coloboration Server версии 7.1.x установленной на Ubuntu server. Описывается настройка GAL в режиме «Внутренний». Использованы материалы из статьи GAL Sync Account, а также Zimbra forum

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

После недавней статьи о стартап-мероприятиях России мы решили не останавливаться на достигнутом и сделать этот мир еще лучше. Для этого мы решили копнуть чуть поглубже и подумать для чего же вообще проводятся все эти мероприятия? Конечно для того чтобы поднять общий уровень проектов. А что самое главное в проекте? Ну разумеется команда! А как можно поднять уровень команды? Естественно обучаться!
Поэтому в следующем посте мы решили сделать небольшой гайд, чему и где стоит учиться стартаперу. Статья разделена на четыре части, по способам потребления информации. Вначале мы немного говорим о книгах и блогах, он самый объемный, потому что в нем говорится о конкретных книгах. Потом немного информации об образовательном видео и подкастах и в конце пара слов о тренингах и образовательных курсах. Разделы так и озаглавлены:
Читать, Смотреть, Слушать и Ходить.

Одно время я работал на free-lance.ru. С утра я обычно мониторил заказы, а после обеда непосредственно работал. Однажды я наткнулся на заказ, сумма за выполнение которого была очень аппетитной. Я сразу отписался по заказу, и буквально через минуту получил ТЗ на проект в личку. Поначалу меня удивила скорость ответа, и то что меня сразу выбрали исполнителем, но с другой стороны такое уже частенько бывало. Файл с ТЗ мне показался странным, в него была встроена ссылка на flash ролик. Проверив файл на вирусы и получив ответ, что угроз не обнаружено, я таки усыпил свою бдительность и щелкнул по ссылке на flash ролик. А щелкать не стоило.

Не могу не поделиться с общественностью прекрасным переводом статьи The Limoncelli Test: 32 Questions for Your Sysadmin Team

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

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

Иллюстраций: 34, символов: 51 609.

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

Есть куча советов как убыстрить отдачу сайта – это и статика через nginx и кластеризация и куча еще всяческих хитрых технологий. Однако во всех книжках, советующих как можно повысить загрузку сайтов можно найти две постоянно повторяющиеся темы – «склеивание CSS/JS» и «включение сжатия».

Сегодня попробую осветить денежные вопросы.
Банковский счет, карты, платежи, PayPal и все такое.
Это продолжение топика HOWTO: свой бизнес в США из России, если кто пропустил.

Уважаемые жители Хабра!

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

Несколько недель назад, мы публично выпустили Gauges API. Несмотря на уже существующий Gauges, было не мало работы во время написания API. Необходимо подробно разобраться с деталями.

1. Пишите документацию во время создания API

Мы допустили ошибку, занявшись подготовкой документации после того как API был практически готов. Проблема в том, что документирование ― отстой. Оставляя эту рутину на потом, когда вы уже рады бы выпустить в свет API, делает работу вдвойне сложнее. К счастью, у нас были те кто проходил это раньше.

2. Будьте постоянным

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

Чтобы решить массив/хэш проблему, мы выбрали в качестве ответа всегда возвращать хэш. Это самое гибкое решение, ориентируясь на наши будущие задачи. Мы смогли ввести новые ключи, без нужды конвертировать ответ от нашего сервиса или выпуска новой версии API.

Замена массивов на хеши означала то, что нам нужно пространство имен (namespace) для массивов с ключами. Далее мы заметили, что не все имело свое пространство имен. И снова, мы придумали правило. В этом случае, все объекты верхнего уровня должны иметь пространство имен, но детям этих объектов или наборам нескольких объектов не обязательны пространства имен.

{users:[{user:{...}}, {user:{...}}]} // нет
{users:[{...}, {...}]} // да
{username: 'jnunemaker'} // нет
{user: {username:'jnunemaker'}} // да

Ну вы поняли. Постоянство ― важно. Всегда следует придерживаться одного формата.

    Наверняка многие из нас хоть раз думали про себя: «Черт побери, и везет же этим американцам!». Это касается многого, от магазинов с доставкой «только в пределах 48 континентальных штатов» до вполне серьезных контрактов, которые срываются только потому, что потенциальный заказчик в США категорически не желает иметь дело с иностранцами.

    В этой статье я попробую осветить процесс создания и администрирования американской корпорации для резидента РФ. Наверняка многие из фактов для самих американцев покажутся тривиальными, однако для жителя России все куда сложнее — увы, это данность. Чтоб не сказать — это Родина, сынок. Оговорюсь сразу — я все это проделал более 2 лет назад, так что, некоторые детали могут быть не совсем актуальны. Но вряд ли что-то поменялось принципиально.

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

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

Встроенные инструменты разработки в Firefox

Перед началом списка было бы неправильно не упомянуть об инструментах, уже встроенных в Firefox. Здесь речь идёт о тех самых инструментах разработки в Firefox Aurora 10 и том функционале, который сегодня можно найти в любом современном браузере.

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



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

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Долгое время я мучился ужасно медленным удаленным логином на свои Ubuntu сервера (все 2 ). Ужасно медленно в данном случае — 2-3 секунды. Не то чтобы это было совсем фатально, но когда логин через ключ — хочется чтобы все работало мгновенно — в конце концов, у нас не 486SX.

Длительное гугление приводило только к стандартным решениям:

1. UseDNS no в /etc/ssh/sshd_config — ускоряет логин в случае тормозного DNS. В моём случае стоял локальный кеширующий DNS, потому и так все было быстро.
2. Принудительное указание IPv4 в SSH клиенте — особо не помогло, видимо не у всех тормозит

И на askubuntu.com вопрос c bounty уныло провисел долгие недели без ответа…