Известный гуру внутреннего устройства Windows и архитектуры ARM Алекс Ионеску опубликовал на ресурсе GitHub исходный текст базовой части гипервизора (инструмент виртуализации). Гипервизор содержит в себе множество замечательных свойств, включая, компактный размер, поддержку современных архитектур микропроцессоров, минимальное использование ассемблера в исходных текстах, а также комментарии по его использованию. При его разработке упор делался на максимальную компактность.



Опубликованный проект является настоящей находкой для системных программистов, а также исследователей по безопасности, которые интересуются низкоуровневыми функциями ОС. Гипервизор получил название SimpleVisor, поддерживает только современные 64-битные системы и был успешно протестирован на совместимость с такими системами как Windows 8.1 на микропроцессоре архитектуры Intel Haswell, а также Windows 10 на архитектуре Intel Sandy Bridge.

Меня зовут %username%, мне n лет и я параноик. И каждый день информационный мир усложняет мне жизнь. Технологий становится больше, порог вхождения в IT снижается, и мы получаем действительность, где грубые ошибки в безопасности это нормально. А еще и мощность вычислительной техники растет с каждым годом. В итоге наши пароли, хранимые как получится, становятся достоянием общественности.

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

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

Поэтому мы придумали свой хакерский подход к хранению и вводу паролей.



Кратко: телефон связан через Bluetooth со специальным девайсом, который эмулирует клавиатуру. Утеря девайса и телефона не позволяют получить паролей. Утеря девайса и мастер-пароля тоже не страшны. Как так? Добро пожаловать под кат (там 7 картинок, но они красивенькие).

Утро 26 ноября началось для меня с интересной новости — ребята из Perfect Privacy опубликовали информацию об уязвимости Port Fail, которая позволяет раскрывать IP-адрес клиентов VPN-сервисов с функцией проброса портов. Я немного понегодовал из-за того, что ее назвали уязвимостью, т.к. это никакая не уязвимость, а особенность маршрутизации: трафик до IP-адреса VPN-сервера всегда идет напрямую, в обход VPN. Вполне очевидная вещь, подумал я, о которой должен знать любой сетевой администратор. Заметка вменяемая и технически грамотная, придраться можно только к слову vulnerability (уязвимость). Но потом за дело взялись СМИ, и пошло-поехало…



Критическая уязвимость во всех протоколах VPN на всех операционных системах. У-у-у, как страшно!

В новости, опубликованной на Geektimes, изначально имевшей желтый заголовок, было сказано о награде в $5000 за найденную «уязвимость» от Private Internet Access — одного из крупнейших VPN-сервисов. «$5000 за типичную, совершенно очевидную любому сетевику вещь?» — подумал я — «Невероятно!», и высказал свое негодование по этому поводу в комментариях, попутно расписав еще одну, не менее очевидную, особенность маршрутизации, с которой сталкивался любой настраивавший работу двух и более интернет-провайдеров на одном компьютере: ответ на входящий запрос не обязательно уйдет через этого же провайдера и с этим же IP, чего запросившая сторона совсем не ожидает. Если мы представим, что вместо второго провайдера у нас VPN-соединение, то отправив запрос на IP-адрес нашего провайдера, при определенных условиях может получиться так, что ответ на наш запрос мы получим с IP VPN-сервера.

Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.

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

Некоторые думают, что кабель — простая штука, почти все кабели работают одинаково и не могут причинить никакого вреда. Однако в случае с кабелями-конвертерами USB Type-C это неверно, судя по результатам тестирования, которое провёл Бенсон Люн (Benson Leung), инженер из подразделений Chrome OS, Chromebook Pixel и Pixel C в компании Google.

Среди прочих трудовых обязанностей, Бенсон занимается проверкой разнообразных кабелей-конвертеров USB Type-C на совместимость с ноутбуками Pixel, смартфонами Nexus 5X, 6P и вообще на соответствие спецификациям USB. Что самое ценное, результаты технических тестов он не скрывает, а публикует прямо на сайте Amazon, где продаются кабели.

В свете недавнего поста про сравнение PostgreSQL и MySQL, в комментариях возникла проблема выбора удобного интерфейса для работы с постгресом. Я сам столкнулся с такой проблемой, решив поискать альтернативы всем известному phpMyAdmin / php*Admin, который считается стандартом у веб-мастеров.

Наконец-то удалось организовать монтаж и тестирование опытных образцов устройства новой версии. Устройства, выполняющего лишь одну функцию, – уничтожение компьютеров. Впрочем, не будем ограничиваться только компьютерами, устройство способно вывести из строя практически любую технику оборудованную USB Host интерфейсом. К примеру, у меня на столе стоит осциллограф с USB интерфейсом (но он ещё пригодится), практически все смартфоны поддерживают USB OTG режим, TV, роутеры, модемы и т.д.

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

Но если вы проводите за своим инструментом до 80% рабочего времени, то желательно убедиться, что вы не тратите время впустую и что работа доставляет вам удовольствие. В этой статье я бы хотел немного рассказать про те инструменты, которыми я лично пользуюсь каждый день, и про то, как они улучшают user experience (и, часто, продуктивность) при работе с консолью и с удаленными серверами в частности.

Проблемы ssh

При работе с удаленными серверами по ssh есть много вещей, которые могут фрустрировать, но основных проблем две, и первая из них принципиально неразрешима в рамках ssh:

1. При высоком round-trip latency (>100 ms) пользовательский ввод появляется с ощутимой задержкой, а при использовании мобильного интернета с edge (latency 1000 ms) работа становится подобна пытке
2. При временных проблемах (несколько минут) с доставкой пакетов, соединение может порваться с write failed: broken pipe, причем узнаете вы об этом только при попытке ввода или при использовании настроек вроде keepaliveinterval

Первая проблема неразрешима потому, что ssh by-design является просто транспортом для байтов, и существующие приложения на это поведение расчитывают. Поскольку ssh не пытается интерпретировать этот поток байтов, он не может осуществлять предиктивный ввод. Лично для меня именно эта проблема наиболее актуальна, поскольку мне приходится работать с серверами в европе и США, и во втором случае задержка составляет около 200 мс и является принципиально неустранимой, по крайней мере до изобретения квантовой коммуникации или чего-нибудь подобного. Вторая же проблема проявляется в наших условиях относительно редко, но всё же неприятно переустанавливать все соединения при сбоях сети (и перезапускать упавшие приложения, если они почему-то не были запущены в screen).

Привет, Хабр!

Мы в Хекслете используем JavaScript не только для очевидных задач во фронтэнде, но и, например, для реализации браузерной среды разработки (наш опен-сорсный hexlet-ide) на React'е. У нас есть практический курс по JavaScript, и один из уроков там посвящен замыканиям. Это важная тема не столько в рамках JS, сколько в программировании вообще. Мы освещаем ее и в других курсах.

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

Я использую замыкания уже достаточно давно. Я научился их использовать, но не до конца понимал как они на самом деле работают, что происходит «под капотом». Что это вообще такое? Википедия не очень помогает. Когда замыкание создается и уничтожается? Как выглядит реализация?

"use strict";
 
var myClosure = (function outerFunction() {
 
  var hidden = 1;
 
  return {
    inc: function innerFunction() {
      return hidden++;
    }
  };
 
}());
 
myClosure.inc();  // возвращает 1
myClosure.inc();  // возвращает 2
myClosure.inc();  // возвращает 3
 
// Ага, круто. А как это реализовано?
// И что происходит под капотом?

Raspbian является рекомендуемым дистрибутивом для всех, кто начинает своё знакомство с Raspberry Pi, проблема лишь в том, что по умолчанию в него включено множество пакетов. А так как очень не многие используют малинку в качестве десктопа, то эти пакеты вряд ли можно считать необходимыми. На просторах Интернета можно найти образы минималистичных версий (например, из этой статьи), но к сожалению 2 представленные там версии (Raspbian Server Edition и Raspbian Minimal) не обновлялись уже более 2 лет.

В связи с этим было решено самостоятельно вырезать из установленной системы все ненужные компоненты. На просторах Интернета была найдена только одна более менее полная статья на английском языке. Большая часть взята из неё с моими небольшими исправлениями и дополнениями.

P.S. У знатоков Linux систем с этим вряд ли возникнут проблемы, а новичкам может быть полезно.

Вступление

В первую очередь надо сказать, что этот продукт уже фигурировал на ресурсах ТМ в этой статье от 2008 года. Однако по прошествии примерно 7 лет картинки потерялись и материал кажется несколько устаревшим.

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

^{We can save the day from dark, from bad
There's no one we need}

Многие из вас используют VPN или прокси в повседневной жизни. Кто-то использует его постоянно, получая доступ к заблокированным на государственном или корпоративном уровне ресурсам, многие используют его изредка, для обхода ограничений по географическому положению. Как вы можете знать, крупные интернет-игроки в сфере стриминга видео, музыки и продажи игр никогда не любили пользователей, которые легко обходят географические ограничения, разблокируя недоступный в их стране контент, или совершая покупки заметно дешевле. За примерами не нужно далеко ходить: Netflix изменил свое соглашение об использовании, добавив пункт о блокировке VPN, всего 2 месяца назад; Hulu тоже грешил блокировкой пользователей, а Steam вообще подозрительно смотрит на не-русскоязычных пользователей из России. В последнее время, компании пытаются блокировать уже не конкретных пользователей, а сами IP-адреса VPN-сервисов, создавая определенные неудобства уже самому VPN-сервису и его пользователям. Похоже, они не используют никаких спецсредств, а блокируют выборочно и вручную. Хоть я и не поддерживаю какие-либо блокировки вообще, меня заинтересовала техническая часть вопроса: можно ли как-то определить использование прокси-серверов и VPN со стороны сервера, не прикладывая особых усилий?
Можно, при определенных условиях. И достаточно точно.

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

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Технологии хранения данных — отдельная тема. Не так давно мы косвенно затрагивали ее в нашем материале об управления дисковым пространством сервера.

Сегодня мы поговорим о том, как команда поискового сервиса Algolia пыталась решить внезапно возникшую проблему с SSD-дисками.

Стандарт WiFi 802.11n использует механизм агрегации кадров для уменьшения накладных расходов при передаче данных.
Для этого несколько кадров объединяются в один. При этом маркер разделителя кадров передается вместе с данными.
Это позволяет сформировать данные, которые при прохождении через WiFi устройство будут интерпретированы им как отдельные кадры.

То есть имея контроль над потоком данных передаваемых от сервера клиенту (например при загрузке файла с сервера атакующего) или от клиента к серверу, можно генерировать произвольные пакеты на всех уровнях OSI:

• Пакет с любыми заголовками RadioTap: Beacon, Probe Request/Respone, Deauthentication
• L2 уровень: указать любой MAC адрес в заголовках пакета, можно производить ARP спуфинг
• L3/L4 уровень: скрафтить любой TCP/UDP/ICMP пакет с любыми заголовками IP
• и так далее

Уязвимости подвержены только открытые сети стандарта 802.11n.

Исследовательский центр CARNet, специализирующийся на применении ИТ-технологий в сфере образования, провел тестирование WiFi точек доступа именитых производителей. Приводим их в алфавитном порядке: Aerohive, Aruba, Cisco, HP, Meraki, Ruckus, Ubiquiti, Xirrus. Испытания проводились по методике силового экстрима – каждый новый подход сопровождался увеличенной нагрузкой. Выдержали не все. Чуть подробнее об эксперименте.

^{Aqua Mine}

Введение

После многолетнего доминирования дисплеев с высокой плотностью пикселей на мобильных устройствах, данная тенденция наконец-то дошла и до лаптопов с десктопами. По моему мнению, производители не ставили HiDPI-матрицы в основном из-за слабой поддержки DPI, отличных от 96, в Windows. К счастью, ситуация заметно улучшилась с выходом Windows 8 с Modern UI, хотя в десктопном режиме все еще далеко не идеальная — люди до сих пор жалуются на 3200×1800 при 13.3" в лаптопах и сомневаются о покупке 4K UHD 23.8"-монитора.

DPI и Linux

Возможность установки произвольного значения DPI появилась еще во времена Xfree86, но следует понимать, что это просто значение, которое ничего не делает само по себе. Его считывают и используют программы и компоненты, которые и принимают решение, каким образом отразить изменение DPI на экране. Если текст следует установленному значению DPI в 95% случаев (спасибо xft!), то размер элементов зависит от используемого окружения рабочего стола и тулкитов, на которых написаны приложения.

GTK+ 3-приложения поддерживают как целочисленный скейлинг элементов и дробный скейлинг шрифтов, так и изменение DPI на лету, без перезапуска приложений. Скейлингом элементов управляет переменная окружения GDK_SCALE, а скейлингом шрифтов — GDK_DPI_SCALE.
По умолчанию, шрифты скейлятся вместе с элементами. Таким образом, при DPI 96 и GDK_SCALE=2, вы получите шрифт, словно он с DPI 192. Чтобы отменить скейлинг шрифтов, достаточно установить переменную окружения GDK_DPI_SCALE в 0.5 (для GDK_SCALE=2).
Qt4 не умеет скейлить элементы. Для применения нового значения DPI требуется перезапуск приложения.
Qt5, начиная с версии 5.4, поддерживает целочисленный скейлинг элементов через переменную окружения QT_DEVICE_PIXEL_RATIO. DPI менять на лету нельзя, как и в Qt4, но работы в этом направлении ведутся и будут доступны с релизом Qt 5.6, как и скейлинг на каждый монитор отдельно.
WxWidgets-приложения ведут себя так же, как GTK+ 3, только не поддерживают скейлинг элементов.

Я попытался выяснить, какие DE можно комфортно использовать с HiDPI-мониторами. Тестирование проводилось на лаптопе с 12.5" 1366×768 (125 DPI) с подключенным внешним 23.8"-монитором с разрешением 3840×2160 (185 DPI).

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

Год назад мы выпустили контроллер Wiren Board Smart Home. Благодаря невысокой цене и широким возможностям он имел успех среди энтузиастов.

Поэтому мы решили не останавливаться и выпустили новую версию — контроллер для автоматизации Wiren Board 4, к которому написали и новый софт.

Несмотря на название, покупатели часто использовали Wiren Board Smart Home и для совсем не “домашних” задач: сбора климатических параметров, опроса счётчиков и датчиков, удалённого контроля оборудования — то есть в качестве универсального логического контроллера.

Wiren Board 4 (как в железе, так и в ПО) лучше приспособлен для таких задач. Домашних пользователей это тоже коснулось — контроллер стал надёжнее.