Антивещество — штука достаточно популярная, как в научной фантастике, так и просто в околонаучных спорах о том, “как все устроено на самом деле”. Фантасты нам подарили звезды и целые планетные системы из антивещества. Дэн Браун через “Ангелов и демонов” донес этот феномен практически до каждого.

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

В данной статье 5 первых заданий, узнаем основы анализа трафика различных сетевых протоколов.

Однажды в телеграм чат питерского сообщества линуксоидов SPbLUG я кинул забавную задачку:

Выведите список файлов в домашней директории максимально возможным количеством способов, без использования ls или его алиасов(1 способ — 1 балл)

Такое же задание чуть позже прилетело в ещё один чат, и вот что из этого получилось:

Пренеприятнейшая история случилась с одним моим знакомым. Но насколько она оказалась неприятной для Михаила, настолько же занимательной для меня.

Надо сказать, что приятель мой вполне себе UNIX-пользователь: может сам поставить систему, установить mysql, php и сделать простейшие настройки nginx.
И есть у него десяток-полтора сайтов посвященных строительным инструментам.

Один из таких сайтов, посвященный бензопилам, плотненько сидит в ТОПe поисковиков. Сайт этот — некоммерческий обзорник, но кому-то поперек горла и повадились его атаковать. То DDoS, то брутфорс, то комменты напишут непотребные и шлют абузы на хостинг и в РКН.
Неожиданно всё стихло и это затишье оказалось не к добру, а сайт начал постепенно покидать верхние строчки выдачи.



То была присказка, дальше сама админская байка.

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

Доброй осени, дамы и господа. Подготовил для вас подборку самых интересных находок из опенсорса за август 2019.

За полным списком новых полезных инструментов, статей и докладов можно обратиться в мой телеграм канал @OpensourceFindings (по ссылке зеркало, если не открывается оригинал).

В сегодняшнем выпуске.
Технологии внутри: Python, Rust, JavaScript, Go.
Тематика: веб разработка, администрирование, инструменты разработчика.

О чём эта статья

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

В этой статье я напишу как устроен алгоритм шифрования AES (которого иногда называют Rijndael) и напишу его на JavaScript. Почему на JavaScript? Чтобы запустить программу на этом языке, нужен только браузер в котором вы читаете эту статью. Чтобы запустить программу, скажем, на C, нужен компилятор и найдётся совсем мало желающих, готовых потратить время на компиляцию кода из какой то статьи. В конце есть ссылка по которой можно скачать архив с html страницей и несколькими js файлами — это пример реализации AES на JavaScript.

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

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

Код доступен на гитхабе. Инструкции по установке — для Linux, macOS и (экспериментально) Windows.

Мы не первый год работаем на рынке информационной безопасности. Основные наши клиенты – правоохранительные органы разных стран, спецслужбы, а также отделы IT безопасности в крупных компаниях. Иногда наши клиенты делятся с нами интересными историями; о некоторых из них можно прочитать и в средствах массовой информации. Сегодня я хочу рассказать несколько историй о людях, которым было «нечего скрывать» и у которых в результате возникли серьёзные проблемы буквально на ровном месте.

В чём проблема?

Я часто пишу статьи на тему информационной безопасности. Иногда получается понятно для неспециалиста, иногда, вероятно, не очень. «Что-то я вообще не понял посыла статьи […] в чем проблема?», «имхо, проблема с icloud, слегка притянута за уши», ну и бессмертное – «я не стал заморачиваться, мне нечего скрывать». Отлично, давайте посмотрим, стоит ли вам что-либо скрывать.

Celebgate: «проблема с iCloud слегка притянута за уши»

С момента выхода нашего первого продукта для извлечения данных из iCloud прошло более пяти лет. Ключ от продукта Elcomsoft Phone Password Breaker (сейчас у него другое название), который на тот момент мы продавали исключительно правоохранительным органам, был украден и попал в руки хакерской группировки.

Тестирую элементы питания на профессиональном оборудовании. Цель охватить большую часть рынка элементов питания Европы и России.

На данный момент протестированы более 230 аккумуляторов и батареек. Сделано более 1000 тестов. Израсходовано 4 ящика батареек и несколько месяцев жизни.

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

В статье показано, как создать нерекурсивную zip-бомбу, которая обеспечивает высокую степень сжатия путём перекрытия файлов внутри zip-контейнера. «Нерекурсивная» означает, что она не зависит от рекурсивной распаковки декомпрессорами файлов, вложенных в zip-архивы: здесь всего один раунд. Выходной размер увеличивается квадратично от входного, достигая степени сжатия более 28 миллионов (10 МБ → 281 ТБ) в пределах формата zip. Ещё большее расширение возможно с помощью 64-разрядных расширений. Конструкция использует только наиболее распространённый алгоритм сжатия DEFLATE и совместима с большинством парсеров zip.

• zbsm.zip 42 kB → 5.5 GB
  
• zblg.zip 10 MB → 281 TB
  
• zbxl.zip 46 MB → 4.5 PB (Zip64, менее совместима с парсерами)

Исходный код:

git clone https://www.bamsoftware.com/git/zipbomb.git

zipbomb-20190702.zip

Данные и исходники иллюстраций:

git clone https://www.bamsoftware.com/git/zipbomb-paper.git

Старые методы по-прежнему работают

[Обновление] Теперь я в каком-то списке спецслужб, потому что написал статью про некий вид «бомбы», так?

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

Когда я в возрасте 13 лет впервые захостил свою маленькую Linux-коробочку с доступом по SSH, я смотрел логи и каждый день видел IP-адреса (в основном, из Китая и России), которые пытались подключиться к моей сладенькой маленькой коробочке (которая на самом деле была старым ноутом ThinkPad T21 со сломанным дисплеем, жужжавшим под кроватью). Я сообщал эти IP их провайдерам.

На самом деле если у вас Linux-сервер с открытым SSH, то можете сами посмотреть, сколько попыток подключений происходит ежедневно:

grep 'authentication failures' /var/log/auth.log

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

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

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

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

Однажды задался вопросом — а как в целом в разных странах, ну и в первую очередь в России, защищаются от этой беды?

Про неконкуренцию

Вообще, уход сотрудника — это 3 «полярные лисички», а не одна.

Ушедший сотрудник:

1. создает свою компанию или устраивается к конкурентам (даже не знаю, что хуже);
2. уносит с собой голову, в которой хранится куча конфиденциальной информации и наработок;
3. уводит сотрудников, как правило, наиболее ценных, чем делает «лисичку» еще полнее.

Как бы ты хорошо ни относился к сотруднику, поневоле задумаешься о разных ограничительных соглашениях, обозначаемых за рубежом общим термином non-competes.

О них и поговорим.

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

Раньше у россиян было одно испытание в году — пережить новогодние праздники, желательно целыми и невредимыми. Новый вызов — 5 + 4 дней в тёплой весенней обстановке на даче или на природе: с лопатами, блюдами на огне, в приятной компании близких и неприятном соседстве клещей. И если с правилами обращения с огнём и клещами знакомы почти все, то с едой какая-то беда: то пересушено, то не дожарено, то невкусно, то расстройство ЖКТ. А ведь каждый из нас с вами просто носитель тайны приготовления еды на огне, гуру администрирования горячих углей и DevOps-шашлыка. Ну что, похоливарим на вторнично-пятничном расслабоне?

Раздел 1. Soft Skills

1. Я молчу на совещаниях. Стараюсь делать внимательное и умное лицо, даже если мне все равно.

Привет, %username%

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

Но я не хочу перечислять то же самое. Я не хочу меряться дозами LD₅₀ и претендовать на оригинальность.

Я хочу написать про те яды, с которыми ты, %username%, имеешь большой риск столкнуться каждый день. И которые не так просты, как их ближайшие собратья.

Врага надо знать в лицо. И надеюсь — будет интересно. А если окажется интересно — то возможно, что и осилишь вторую часть.

Итак — моя смертельная десятка!

Горячие клавиши используют все. Банальные Ctrl+C и Ctrl+V, а сколько раз выручал Ctrl+Z? Ну а Alt+F4? А если вспомнить количество негативных отзывов, когда в новых MacBook Pro добавили тачбар и вырезали ряд командных клавиш?

Увидел хороший гайд по полезным хоткеям и небольшим советам в Unreal Engine, которые точно упростят левел-дизайнерам жизнь. Перевод под катом.

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

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

Человек, как известно, существо ленивое. А тем более, когда касается вопроса выбора устойчивого пароля.

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