Update
Новый вариант порошка и более подробный разбор во второй части: DIY порошок для посудомойки: разбираем промышленные средства и улучшаем рецепт

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

Есть очень много областей нашей жизни, где наше представление формирует исключительно маркетинговый буллшит. Увы, большинство людей даже не пытаются задумываться о том, что лежит в основе всего этого. Очень часто рыночная ситуация приводит к тому, что себестоимость продукта составляет 0.5% от его цены. Остальное маркетинг, наценки, логистика, упаковка и тому подобное. Почти все в курсе про концепцию продажи чернил для принтера по цене слез гималайских девственниц и настойчивые рекомендации производителей использовать только оригинальные расходные материалы. Например, совсем недавно меня озарило, что 1.5 грамма сухого вещества во флаконе удобрений для растений не могут стоить 200-250 рублей. А ведь именно такое количество может уместиться в относительно стабильном состоянии в виде раствора. Я сразу представил себе гектары полей и грузовики, которые везут тонны порошка. В результате перешел на расфасовки по 1 кг Буйских комплексных сухих удобрений. Можно ванну раствора приготовить.

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

TLDR:

70% прокаленной соды и 30% стирального порошка вместо моющего средства.
Если очень лень возиться с содой, то просто порошок Биолан или его аналоги. Сода удешевляет.
Пищевая соль «Экстра» вместо соли.

Сегодня я расскажу вам как можно «оторваться по полной» на ниве домашней автоматизации и получить ни с чем несравнимое удовольствие от процесса создания, настройки и эксплуатации своего Умного дома. Речь пойдёт о реконфигурируемом с точностью до одного пина микроконтроллере на 192 линии контроля/управления, масштабируемом и работающим под неким подобием операционной системы с полноценным веб-интерфейсом. Каждый такой контроллер может содержать сотни сайтов и таких контроллеров в вашей сети может быть сколько угодно. Похоже, будущее уже наступило.

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

Думаю, что у каждого пользователя Android рано или поздно возникает необходимость понять, какое приложение за ночь съело всю батарею притом, что телефон лежал с погашенным экраном. Участь найденного виновника не завидна: чаще всего его просто удаляют. Итак, что же сделать, чтобы наши приложения использовали аккумулятор минимально? В статье я постараюсь дать ответ на этот вопрос и рассказать о подходах к уменьшению потребления аккумулятора, которые мне доводилось использовать.

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

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

Я пропущу описание протокола и процесса подключения к аккаунту хостинга по SSH, в сети можно найти множество видео-уроков и статей по данной теме, скажу лишь что для подключения вам потребуется программа Putty (ОС Windows) / Терминал (Mac OS X) или аналогичные, и доступы к хостингу по SSH: хост, порт, логин и пароль (часто имя и пароль они совпадают с доступом в cPanel, ISPManager или аккаунтом панели управления хостингом).

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

Предположим, вы заметили подозрительную активность на сайте (стал медленно открываться, пропали доступы в админ-панель, с сайта рассылают спам и т.п.). Первое, что в этом случае нужно выполнить – это проверить файлы сайта на вредоносный код специализированными сканерами. Но пока сайт сканируется, можно провести экспресс-анализ логов веб-сервера с помощью команд find/grep, чтобы опеределить, не было ли обращений к каким-то подозрительным скриптам, попыток брутфорса (подбора пароля) или вызовов хакерских скриптов. Как это сделать? Об этом ниже.

На сегодняшний день самыми популярными дистрибутивами для тестирования на проникновение являются *nix-like дистрибутивы: Kali Linux, BlackArch Linux, Pentoo, Whonix и многие другие. Они могут использоваться как в виртуальной среде, так и в качестве live системы или вообще быть установлены в виде десктопной ОС.

Windows пользователи до недавнего времени были обделены (виртуальные машины не берем во внимание) такими сборками, пока не появилась волшебная коробочка — PentestBox.

Интро

Не так давно я выступал на конференции FrontendConf 2015 (РИТ++) с темой данной статьи. И при подготовке доклада начал искать информацию, а кто вообще выступал на данную тему и что есть в Сети на данный момент.

Оказалось, что информации совсем немного, более-менее можно было бы отметить доклад mikewest.org/2013/09/frontend-security-frontendconf-2013 от Mike West из компании Google, но какой-то «непентестерский» взгляд и уж совсем мало материала. И www.slideshare.net/eoftedal/web-application-security-in-front-end где тема раскрыта более детально, но выступление 2011 года. А за 4 года технологии и атаки на месте не стояли.

Долго и сложно выбирая темы, что же все-таки рассказать разработчикам фронтендов про безопасность, при этом минимум касаясь бекэнда (местами все-таки это неделимо), получился доклад, а здесь — его текстовый пересказ.

О чем вообще разговор?

А действительно, о чем тут вообще можно разговаривать? Говоря про взломы и безопасность невольно приходят в голову тезисы — слили базу, получили доступ к выполнению команд ОС на сервере, прочитали чужую переписку. Но это все — server side код. А что ж может «нагородить» фронтэндер? Главная опасность, конечно же, в обходе атакующим SOP — Same Origin Policy, главной политики безопасности браузеров, которая регулирует работу в разных Origin. Но не только, давайте разбираться.

Описанная проблема присуща только ветке OpenVPN 2.3, в 2.4 размеры буферов не меняются без требования пользователя.

Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием OpenVPN и получают низкую скорость, сильно ниже скорости канала. У кого-то это может быть 20 Мбит/с при канале в 100 Мбит/с с обеих сторон, а кто-то еле получает и 400 Кбит/с на 2 Мбит/с ADSL/3G и высоким пингом. Зачастую, таким людям советуют увеличить MTU на VPN-интерфейсе до чрезвычайно больших значений, вроде 48000, или же поиграться с параметром mssfix. Частично это помогает, но скорость внутри VPN все еще очень далека от канальной. Иногда все сваливают на то, что OpenVPN — userspace-решение, и это его нормальная скорость, учитывая всякие шифрования и HMAC'и. Абсурд!

Немного истории

На дворе июль 2004 года. Типичная скорость домашнего интернета в развитых странах составляет 256 Кбит/с-1 Мбит/с, в менее развитых — 56 Кбит/с. Ядро Linux 2.6.7 вышло не так давно, а 2.6.8, в котором TCP Window Scale включен по умолчанию, выйдет только через месяц. Проект OpenVPN развивается уже 3 года как, к релизу готовится версия 2.0.
Один из разработчиков добавляет код, который устанавливает буфер приема и отправки сокета по умолчанию в 64 КБ, вероятно, чтобы хоть как-то унифицировать размер буфера между платформами и не зависеть от системных настроек.

^{Источник: Spacefacts.de}

Эта история произошла в 1985 году, но в последствии постепенно забылась. Шли годы — многие подробности были искажены, кое-что было выдумано. Даже те, кто первыми рассказал об этих событиях, допускали явные ошибки. Операция «Союза-13» по спасению орбитальной станции «Салют-7» была впечатляющей попыткой проведения ремонта в открытом космосе. Писатель Николай Белаковский собрал все факты воедино и готов впервые за все время предоставить нам полноценный рассказ о тех событиях.

Привет, Хабровчане!

Сегодня хотелось бы поделиться опытом создания устройства для защиты периметра сети небольшой организации, построенного на базе open source решений: стандартного линуксового межсетевого экрана NETFilter с графическим интерфейсом Firewall Builder, системы обнаружения и предотвращения вторжений Suricata с веб-интерфейсом Snorby и шлюза удаленного доступа OpenVPN на одной виртуальной машине.

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

Всех заинтересовавшихся приглашаю под кат.

В жизни каждого мужчины наступает момент, когда трафик растёт и сервак умирает необходимо задуматься об оптимизации. В последнем дайджесте PHP (№ 40) была упомянута ссылкой статья «How GZIP Compression Works». Исходя из статистики, 56% веб-сайтов используют GZIP. Я надеюсь, эта статья раскроет перед читателем достоинства этой технологии.

Для мониторинга IT-инфраструктуры мы используем множество инструментов, в том числе:

• Zabbix — о нем написано немало статей здесь на хабре. Нам очень нравятся его возможности низкоуровневого обнаружения, но его возможности визуализации данных оставляют желать лучшего.
• Graphite — система, которая хранит данные и имеет удобный интерфейс для их отображения. Сейчас мы импортируем в нее метрики из Zabbix и храним историю.
• Shinken — система мониторинга, которая основана на Nagios и написана на языке Python. Сейчас мы присматриваемся к ней. Нам нравится то, что в нее очень просто импортировать данные из системы документации сети Netdot (о ней я уже писал ранее), а также она легко интегрируется с Graphite.

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

• Skyline
• Oculus

Задача: Настроить телефоны (или любой другой абонентский девайс) автоматически на основе MAC-адреса, желательно не доставая устройство из коробки.

Идея централизованной настройки абонентских устройств давно была у меня и, наконец, нашла свою реализацию в одном из проектов. Видео в конце поста.
Практически все (Cisco, Polycom, D-Link, Escene) IP-телефоны, с которыми мне доводилось встречаться, в том или ином виде поддерживают централизованную настройку с сервера, т.е. Auto-Provisioning по нашему автопровизия. В данном случае рассмотрен пример с телефонами Polycom, но по сути, аналогичный подход позволит настроить любой телефон с определенными корректировками.

Как это работает (про Polycom)?

Телефон по умолчанию настроен на получение IP-адреса по DHCP, помимо самого адреса телефон получает от DHCP ряд опций в числе которых обычно указываются шлюз, маска сети и DNS- сервер, кроме того можно указать SNTP-сервер и еще много чего. Polycom’ы смотрят по умолчанию в опцию 66 и 160, там они пытаются найти адрес/имя сервера автопровизии. Если телефон обнаруживает адрес сервера, он пытается подключиться к нему по уполчанию через FTP (поддерживает еще HTTP, HTTPS, TFTP), используя в качестве логина и пароля:

Username	PlcmSpIp
Password	PlcmSpIp

Телефон запрашивает у сервера версию (файл sip.ver) и сами файлы прошивки и конфигурационные файлы. Телефон выкачивает новую прошивку, обновляется, затем после перезагрузки снова обращается к серверу, видит, что ПО не требует обновления, скачивает и применяет конфигурационные файлы в формате XML. В общем случае аппарат запрашивает следующие файлы.