IT

Google и Microsoft забирают рынок электронной почты Исследование показало, что за последние десять лет доля компаний с собственными почтовыми серверами просела в два раза — с 44,6% до 22,4%. Рынок забирают облака: у Google Workspace уже 21,8%, а у Microsoft 365 — 16,8%. Для сравнения, у ближайших конкурентов в лице Proofpoint и Яндекс 360 всего 1,9% и 1,6% соответственно. Каждые три месяца независимые серверы теряют еще по 1,5 процентных пункта. Главная проблема здесь в фильтрах. Google и Microsoft постоянно ужесточают правила приема почты для сторонних IP-адресов. В итоге письма с поднятых вручную серверов всё чаще молча режутся или улетают в спам, а админам приходится сдаваться и переводить компании на платную почту IT-гигантов.

🟦 Что такое LLMNR и почему он опасен? Когда мы открываем ресурс в Windows, например:

\\fileserver\documents

компьютеру нужно понять:

"Какой IP-адрес у этого имени?"

Обычно этим занимается DNS. Но что происходит, если DNS не знает ответ? Windows может использовать дополнительные механизмы поиска: — LLMNR — NBNS — mDNS И именно здесь появляется интерес для пентестера. 🧠 Что такое LLMNR?

LLMNR (Link-Local Multicast Name Resolution) — это протокол разрешения имён внутри локальной сети.

Его задача:

помочь компьютерам найти друг друга без участия DNS-сервера.

Например: Пользователь вводит:

\\fileserwer\share

Но такого имени нет в DNS. Тогда Windows отправляет запрос:

Кто такой fileserwer?

Этот запрос получает вся локальная сеть. 💀 Где проблема? Windows доверяет ответу внутри сети. Например: Настоящего сервера нет. Атакующий отвечает:

Я fileserwer.

Windows думает:

Отлично, подключаюсь.

И может попытаться выполнить NTLM-аутентификацию. Схема:

Пользователь
      |
      | "Где fileserwer?"
      |
      ↓
    LLMNR
      |
      ↓
Атакующий отвечает:
"Это я"
      |
      ↓
NTLM Authentication

🛠 Почему это интересно пентестеру? Потому что позволяет проверить: — используется ли LLMNR; — можно ли получить NTLM-аутентификацию; — есть ли условия для NTLM Relay; — насколько правильно настроена внутренняя сеть. #llmnr #ntlm #responder #windows #ad #pentest #infra

Про ИИ и его принятие график. График демонстрирует прямую корреляцию между долей разработчиков в штате и уровнем внедрения искусственного интеллекта в компаниях США по секторам экономики. Основные оси и параметры * Ось X (горизонтальная): Доля разработчиков ПО от общего числа сотрудников в секторе (Software developers as % of employees), от 0% до 12%. * Ось Y (вертикальная): Процент компаний в отрасли, внедривших ИИ (AI adoption, % of companies), от 0% до 50%. * Красный пунктир: Линия тренда, показывающая сильную положительную связь — чем выше концентрация технических специалистов, тем активнее отрасль берет на вооружение технологии ИИ. Ключевые выводы по секторам * Лидеры внедрения (правый верхний квадрант): Сектор информационных технологий (Information) лидирует с большим отрывом: разработчики составляют почти 11% штата, а уровень внедрения ИИ превышает 40%. За ним следуют профессиональные услуги (Professional services) — около 6,5% программистов и более 40% внедрения. * Специфика финансовых услуг (Finance): Финансовый сектор внедряет ИИ заметно активнее (около 37%), чем предполагает общая линия тренда при его относительно скромной доле разработчиков (~3%). Это объясняется ранними инвестициями в алгоритмический трейдинг, скоринг и анализ рисков. * Традиционные отрасли (левый нижний кластер): Производство (Manufacturing), транспорт (Transportation), здравоохранение (Health care) и смежные секторы имеют низкую долю программистов (менее 1–1,5%) и, как следствие, относительно невысокий уровень внедрения ИИ (в диапазоне 10–25%). --- * В секторах вроде финансов внедрение ИИ часто идет через покупку готовых корпоративных платформ и API, что снижает потребность в собственной огромной армии программистов для базовой автоматизации. * Разрыв между ИТ-сектором и тяжелой индустрией в графике отражает так называемое "бутылочное горлышко данных": на производстве или в логистике критически сложнее оцифровать физические процессы, чем программный код или тексты. * В 2026 году появление автономных кодинг-агентов начало менять эту пропорцию: малые команды инженеров получают возможность разворачивать решения масштаба прежних ИТ-отделов.

Немного про пайплайн На скрине локация из Still Wakes the Deep. Этот же скриншот — наглядная иллюстрация того, почему при разработке игры, левел дизайнерам очень желательно самим тестировать уровень после работы арт отдела. Понятно, что это ещё делают тестировщики, само собой, но есть более тонкие моменты, чем на скриншоте, где нам очевидно, что персонаж должен был бы провалиться в отверстие в полу. Как такие ситуации чаще всего происходят: есть пол от левел дизайнеров, но он визуально неинтересный. Художник по окружению добавляет сценку, где есть отверстие в полу, дающее доступ к трубам, разные инструменты разбросаны вокруг. У игрока впечатление, что кто-то здесь ремонтировал трубу или сам пол, не так важно. Всё вроде бы хорошо, но есть нюанс. Левел артист скорее всего либо забыл подправить коллайдеры пола, либо не мог подправить самостоятельно (такое бывает, если этим занимаются в отделе левел-дизайна, например технический ЛД). Может, левел артист даже передал эту информацию тому левел дизайнеру, который должен был разбить коллайдер на мелкие части или добавить меш коллайдер. А ЛД об этом забыл. А может, какой-то начинающий специалист делал эту сценку, и просто забыл о коллайдере или упустил этот момент, и такое тоже бывает. Или не успевали. Причин может быть очень много. И QA даже могли этот уровень тестировать, но не перепроверить конкретно момент с коллайдером, потому что не подумали о нём, или не обратили внимание, что появилась эта дыра в полу. Или QA тоже не успевали подробно всё протестировать. Но так или иначе, где-то оно затерялось и не было сделано. Именно поэтому дизайнеру уровней очень желательно (если не обязательно) всегда перепроходить уровень после финального прохода арта. Нельзя сказать, что это на 100% убережет от всех подобных багов, но поможет существенно их минимизировать. А ещё это важно потому, что ощущения от уровня в графике финального качества (это ведь не только материалы, текстуры и пропсы, ещё и звуки, освещение и эффекты) могут быть совершенно другие. Но это, пожалуй, тема для отдельного поста) #StillWakesTheDeep #leveldesign #анализ

Наша привычная рубрика #будущности. Это такие "новости", но которые еще не произошли, а только запланированы. Всегда в будущем времени со словами "могут", "хотят", "думают", "планируют". Но по сети ходят еще цифры, которые описывают строительство этих самых ЦОДов в деньгах. Например: * Строительство здания и инженерной инфраструктуры ЦОДа уровня Tier III обходится в 0,9-1,4 млрд рублей за 1 МВт IT-мощности. . Для хабов с повышенными требованиями к охлаждению показатель превышает 1,5 млрд рублей за 1 МВт. * По оценке Минэнерго, текущая мощность российских ЦОДов без майнинга составляет 1,7 ГВт, а потребность для задач искусственного интеллекта вырастет до 2-2,5 ГВт к 2030 году. * Вычислительное оборудование в эту сумму не входит. Берем в руки калькулятор и выясняем, что для реализации будущности нужно от 270 до 420 млрд рублей минимум (+300 МВт) и от 720 млрд до 1,2 трлн на "взрывной рост ИИ". Это только на инфраструктуру, напомню. Но собственно оборудование ИИ - там есть эмпирический коэффициент - х10. То есть, сумму инфраструктуры умножаем на десять. И получаем, что * Минимальная оценка необходимых инвестиций: 270 + 2700 =2.970 млрд рублей (35 млрд долларов) * Верхняя планка: 1,2 + 12 =13,2 триллионов рублей - 150 млрд долларов. Это, напомню, до 2030 года. Кажется, что это далекое будущее, но нет — 2027, 2028, 2029 и сам тридцатый год. Четыре года. Меньше, чем уже идет сама война. По минимуму 8-9 млрд долларов в год. Так вот, я очень сомневаюсь, что в ИИ РФ сможет вложить больше пары миллиардов долларов в год. А уж на "взрывной рост ИИ" я б не рассчитывал вовсе. Давайте просто признаем, что ИИ-гонку РФ проиграла. И это навсегда.

Фейсбук прислал письмо, что мне обязательно нужно настроить паскей. Это довольно хитрая технология, но суть в том, что в защищенной памяти телефона или ноутбука хранится специальный ключ, привязанный к сайту, который его выдал. Эта привязка супер важна, потому что 90% атак в интернете — это фишинг, когда мы вводим пароли и одноразовые коды на сайте, который выглядит как вконтакте / телеграм и тд., а на самом деле это сайт-обманка, сделанная хакерами. Паскей технически невозможно ввести на поддельный сайт. Редкий случай, когда у реальной проблемы нашлось техническое решение. Наш компьютер проверяет сервер так же, как и сервер проверяет нас. А ещё сайты могут использовать его для авторизации без ввода логина/имейла/номера телефона. Просто кнопка «войти с паскей», идентифицируетесь по биометрии или пинкоду с устройства, где хранится ваш ключ и вуаля! Помню, как лет 10 назад на конференциях по безопасности facebook и google раздавала аппаратные ключи с дедушкой этой технологии, U2F, а теперь вот уже можно и логин не вводить. Будущее уже наступило!

6 лет разработки после работы - и первая игра наконец вышла в Steam Rogue Blight - roguelite с souls-like боями и картой в духе Slay the Spire. Проходи постоянно меняющиеся уровни, подстраивай билд под находки. Смерть сурово наказывается. Вперёд ведут только навыки и упорство. Разработчик Rogue Blight шесть лет делал свою первую игру параллельно с работой на полной ставке. Проект занял огромное количество вечеров и выходных, а за это время было немало моментов, когда он всерьёз сомневался, что вообще сможет довести игру до релиза. Несмотря на постоянные задержки, переработки и усталость, разработку удалось закончить. Для автора это не просто очередной релиз, а завершение проекта, который занимал значительную часть его жизни на протяжении нескольких лет. Теперь Rogue Blight официально вышла в Steam. Автор пишет, что до последнего с трудом верил, что когда-нибудь сможет сказать эти слова, и считает релиз исполнением своей давней мечты. Хорошее напоминание о другой стороне инди-разработки: не каждый проект растёт за несколько месяцев и собирает десятки тысяч вишлистов. Иногда главный результат — просто дойти до релиза после шести лет работы и не бросить игру по дороге. Ссылка на игру #инди | Telegram | YouTube | чат

«Как я подключил три телевизора, два компьютера и приставку к одному кабелю интернет-провайдера. Гайд перед ремонтом» Один коллега решил не тянуть кабель к телевизору в дальней комнате. Роутер рядом, Wi-Fi ловит нормально, отдельная линия казалась лишней тратой. Через несколько лет Wi-Fi-модуль в телевизоре сгорел, модель устарела, запчасть найти негде. Пришлось покупать второй такой же телевизор, чтобы переставить один компонент. Была бы розетка рядом, хватило бы обычного патч-корда. Другой коллега поступил наоборот и заложил самую дорогую витую пару под 10-гигабит, которого ни у кого пока нет. Тоже промах, но по своей причине. Между этими двумя крайностями и живёт вся домашняя разводка, которую закладывают до чистовой отделки, когда потом уже не вскроешь.

Прибытие IBM PC. Часть вторая. Цунами Для энтузиастов начала 80-х IBM была воплощением неповоротливой корпорации, неспособной понять, что происходит. А кумиром считалась Digital, та самая, что вдохновляла создателей первых микрокомпьютеров. Когда IBM выкатила свой PC, у Digital, казалось, было преимущество игры на своём поле. Вместо одного ответа IBM компания запустила сразу три персональных компьютера, и все три начали грызться между собой. Проекты воевали за программистов и партнёров, одна команда, по слухам, отговаривала создателей культовой электронной таблицы делать ставку на компьютер соседнего отдела. Глава компании, годами презиравший саму идею персоналки, оказался королём всех этих проектов одновременно, а разработку нужного пользователям софта пустили на самотёк с расчётом, что за хорошим железом он придёт сам. Обсудим, во что обошлись Digital эти три ставки и как та же волна IBM позже накрыла даже саму себя.