Трафик проходящий по витой паре может быть прослушан абсолютно незаметно для участников соединения.
В этом посте будет показано как изготовить автономный сниффер с возможностью сохранения дампа на диск и управляемый по Wi-Fi.

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

Тут я рассмотрел вопросы про ТК для windows-сетей, т.к. с ними я возился много больше. Частично советы касаются и linux-терминалов, но там, вероятнее всего, есть своя специфика.

Вопросы, которые вы должны для себя прояснить до покупки:
1) Порядок, сколько вам их нужно <20, 20-50, 50-100, 100+
2) Вы готовы к тонким клиентам со стороны сервера? Прощай сканеры, прощай банк-клиенты, прощай дешёвые host-based принтеры (включая струйный принтер у дизайнера), прощай PERSW у бухгалтеров.
3) Будут ли ТК за пределами достижимости специалистов? (филиалы, малые подразделения).

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

Перед покупкой вы должны полностью представлять себе, кто будет работать на ТК, кто не на ТК. Лучше всего перед этим сделать пару «самодельных» ТК (грубо говоря, винды с mstsc) и посмотреть на процесс работы их на разных рабочих местах. [на этом этапе я полагаю, что вопросы функционирования терминальных серверов вы решили, потому что это существенно более серьёзная работа].

Повсеместное распространение NAT казалось препятствует свободному обмену трафиком между компьютерами, находящимися за одним из них, и практически делает это невозможным, если оба компьютера скрыты за разными NAT серверами, естественно если вы не администратор обоих NAT серверов. Однако Samy Kamkar легко и непринужденно не только преодолел это, но и сделал программу которая позволяет преодолевать подобные препятствия. В настоящее время данная программа доступна только пользователям *nix подобных систем.

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

Клиент может подключаться через такой сервер к любым ресурсам, либо только тем что ограничены сервером pwnat. Данный инструмент основан на построении UDP-тоннеля. Принцип работы весьма оригинальный и прекрасно описан автором, рекомендую ознакомиться, ибо решение данного вопроса оказалось весьма интересным и неожиданным. Давно не встречал ничего подобного.

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

Найти хорошего программиста – это большая проблема. За свою жизнь мы наняли около 50 программистов исходя из интервью и только интервью. Редкий случай был успехом.Проблемы начинались оттуда, откуда их не ждешь.

• Один не мылся и вонял так, что в комнату не зайти. Я угрожал поставить вытяжку и вычесть из зарплаты; это помогало на один душ, не больше.
• Другой пил запоем и врал, что отравился брюшками семги.
• И все, почти все затягивали сроки.

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

Поиск кандидатов

Очередного программиста я нашел так: отобрал несколько откликов на HeadHunter.ru и попросил их посмотреть, чем они займутся. Вот что я написал:

Давайте каждый попробует ответить на вопрос: как установить 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 и подумать, можете ли вы переложить на него часть своей работы.

Думаю, каждый из нас с вами сталкивался с проблемой, когда из-за глюка прошивки фотоаппарата, камеры, кпк, смартфона или просто из-за особого устройства /dev/hands карточка была отформатирована, данные были удалены. В свое время данную проблему я решал достаточно просто, используя Portable версию Ontrack Easy Recovery, но так как уже несколько лет являюсь пользователем linux систем, то использование данного нелицензионнного приложения через wine показалось не совсем кошерным, к тому же жажда исследований и приключений требовала найти бесплатный родной аналог для linux систем. Исследования закончились, даже не успев начаться, так как первая строчка в поиске Google привела к набору утилит TestDisk, о которых я расскажу далее подробнее.

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

Новая программа венчурного фонда Foundation Capital проводится под лозунгом «Мы рады одолжить вам денег». Если находится предприимчивый специалист, то ему дают месячную стипендию до $15 000 и выделяют рабочее место в офисе примерно на шесть месяцев. Затем спрашивают, не придумал ли он чего-нибудь. Если получилось что-нибудь стоящее, то компания получает право первой инвестиции. Это так называемая модель «штатных предпринимателей» (entrepreneur in residence, то есть E.I.R.).

Итак, родилась у меня как-то давным давно идея сделать свой собственный мониторинг с б/ж и ш.

Необходимо было мониторить успешные входы по ssh(и использование sudo) и сообщать мне об этом. Для оповещений был выбран мессенджер centerim (в дебиан и подобных пакет называется centericq-utf8). Так же понадобится пакет screen.
aptitude install screen centericq-utf8

Скриптик выглядит как-то так:

#!/bin/bash
token=$(curl -s www.google.com/accounts/ClientLogin -d Email=user.name@gmail.com -d Passwd=qwerty -d accountType=GOOGLE -d service=writely -d Gdata-version=3.0 |cut -d "=" -f 2)
set $token
curl --silent --header "Gdata-Version: 3.0" --header "Authorization: GoogleLogin auth=$3" "http://docs.google.com/feeds/user.name@gmail.com/private/full" | tidy -xml -indent -utf8 -quiet > /tmp/gdocs.xml
file=(doc1 doc2 doc3 doc4)
resourceId=(document:0ASpnxqo7zPlfZGQ3Z2Zwc183NWZteDNiM2Y ...) # и ещё 3 resourceId
i=0
while (( i < 4 )) # match num_files
do
wget --header "Gdata-Version: 3.0" --header "Authorization: GoogleLogin auth=$3" "https://docs.google.com/feeds/download/documents/Export?docID=${resourceId[$i]}&exportFormat=txt" -O /tmp/${file[$i]}.txt

sleep 2
i=$i+1
done

А теперь, как принято, разоблачение.

Здравствуй, Хабр!
Предлагаю твоему вниманию простой и в то же время эффективный метод борьбы с http DDoS. На основе сервера Xeon 2.5GHz / 4Gb RAM / SAS можно отражать атаку примерно до 300 Мбит/с (значение получено методом экстраполяции).

Способ реализация

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

Область применения

Борьба с Http DDoS на выделенном сервере или ВПС. Максимальная возможная мощность сдерживания DDoS атаки ограничивается физическими возможностями сервера и пропускной способностью канала.

SEO под DDoS-ом

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

Стоимость и эффективность

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

В данной статье рассматривается такой инструмент мониторинга, как Munin. Странно, но поиск уверяет меня, что статьи о нем на Хабре еще не было. Этот инструмент существует под *NIX (Linux, xBSD, Solaris) и Windows и позволяет централизовано отслеживать и наглядно отображать состояние подшефных систем. Изначально используется для отрисовки графиков, но также его можно использовать как чистое средство для наблюдения. Большой плюс Munin — гибкость (все графики рисуются плагинами, активными на целевых системах, и никто не запрещает использовать только те плагины, которые нужны) и возможность с одного сервера собирать информацию о множестве других. Соответственно, нагрузка на наблюдаемом сервере минимальна. Интересно? Добро пожаловать под кат

Вы уже используете runit на своих серверах? Теперь у Вас есть возможность наблюдать за состоянием сервисов и управлять ими через минималистичный Web-интерфейс.


Для работы этой утилиты Вам нужно поставить ruby и rubygems, и затем выполнить
gem install runit-man thin

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

Попробовал расковырять. Взял код, отформатировал, стал дебагать… Хм, интересно… В коде идет вызов (после приведения к читабельному виду)

window['eval'](var2);


А вот в var2 — бинарные данные. Ух ты… Но ведь eval не может выполнять бинарные данные!!!

Супервизор сервисов runit позиционируется как замена стандартным скриптам инициализации Unix.

Но на практике оказалось, что runit идеален для управления сервисами безотносительно инициализации и т.п.

Введение

Супервизор берёт на себя такой функционал, как:

• превращение любого процесса в демон;
• логгирование вывода процесса и ротирование логов;
• запуск, остановка, рестарт, запрос состояния, управляющие скрипты для init.d;
• выключение и запуск сервисов автоматически при появлении новых сервисов в списке либо удалении старых из списка;
• возможность ведения нескольких независимых списков сервисов одновременно (например, для каждого пользователя отдельно и для системы в целом);
• удобный API для управления сервисами.

Для большинства операционных систем runit уже входит в репозитории пакетов (apt-get install runit). Кроме того, мы имеем уже готовый набор рецептов для популярных сервисов (nginx, apache etc.).

Привет, хочу рассказать о том как один из крупнейших банков заботится о защите персональных данных и соблюдает закон о банковской тайне.
Итак, сразу к делу. Есть на сайте Приватбанка страница на которой агенты или сотрудники привата могут просматривать историю поданных заявок. Что нужно чтобы войти в систему? Для этого сотруднику или агенту нужно ввести свой номер мобильного телефона, ИНН, номер паспорта, или… у каждого сотрудника есть LDAP логин. Далее самое интересное. Не так давно (когда приват стал сотрудничать со скайпом), всем работникам банка поставили скайп. А в качестве логина был присвоен LDAP логин.
А теперь допустим что я хочу посмотреть историю клиентов работника Приватбанка, мне нужен этот логин. Расшифровывается он так: сначала код города, например для Днепропетровска это dn, затем дата рождения, например 010180, и первые буквы с ФИО, например если работник Иванов Иван Иванович, то это iii. Сложив все вмести будем иметь логин: dn010180iii.
Как найти реальный логин? Запускаем поиск скайпа и ищем. Например:

Вводим логин на странице истории и видим клиентов, а так же их контактные данные, например телефоны:

За минуту поисков можно найти еще несколько логинов:
lv140782mvv
lv131085sma
lv141183raj
Ну и конечно же вопрос, почему данные находятся в общем доступе?.. Ведь еще неизвестно как эти данные могут быть использованы злоумышленниками.

Заметка посвящена не столько возможным методам защиты (о них уже было много написано), сколько обзору небольшого списка для быстрой проверки при подготовке к возможных скачкам посещаемости. Судя по статистике нагрузки на электронные магазины на прошлой неделе (когда начался рождественский сезон продаж на Западе), даже для крупных магазинов время ответа может колебаться на 20%, что же говорить о менее крупных веб-сайтах?

Такую проверку обязательно нужно проводить перед выпусками новых продуктов, а также перед сезоном массовых покупок (для России это время в канун Нового Года и Рождества). Итак, с чего начать?

В этой статье я хочу рассказать, о том, как можно внедрить систему сборки deb-пакетов для некоторого абстрактного проекта. Плюсов в распространении и развёртывании ПО на основе пакетов несколько:

• Атомарность пакета (представление продукта в виде одного файла);
• Наличие скриптов пред/пост установки/удаления ПО;
• Возможно указания зависимостей для ПО.

Кроме того, при развёртывании ПО на основе пакетов, а не на основе SVN, вы гарантировано защищены от проблем с .svn-папками.

Ко мне очень часто поступают довольно интересные и нестандартные задачи по настройке серверов.

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

В моем случае — надо было заблокировать CN полностью, на RU отдавать полный канал, а на остальные страны — в два раза меньше.

Разумеется, вбивать полностью все подсети руками неудобно, да и они часто меняются. Логичнее всего было сделать это с помощью geoip.

Иногда скорость роста проекта несколько выше чем скорость оптимизации веб-приложения или приобретение более мощного оборудования под backend.

Наиболее простая схема «распараллеливания» нагрузки — вынос основной нагрузки на несколько frontend. Раньше приходилось мучиться (или наслаждаться, кому как) с webdav'ами, кластерными ФС и прочими хитростями чтобы обеспечить актуальную информацию, так было до тех пор, пока не появился nginx, а точнее proxy_store и proxy_cache в нём.

Начиная с версии 0.8.11 в nginx появилась новая возможность для раздачи статики — использование AIO (Asyncronous Input-Output — неблокирующий ввод-вывод) для Linux и FreeBSD.

Чем это событие знаменательно? До этого момента nginx использовал неблокирующий режим только при работе с сетью — любая работа с файлами блокировала рабочий процесс. К чему это приводило? Если у вас есть много разного контента, который не весь находится в кэше ОС (фотохостинг, etc) — то рано или поздно все 50, 150, 200 процессов будут ждать дисковые операции и не смогут обслужить нового клиента — даже если нужный ему контент можно отдать из файлового кэша или запросить с бэкенда.