Характеристика, которую пишут в описании правила детектирования и произносят на защите архитектуры: обнаруживает 99% атак при доле ошибок в 1%. Звучит как хороший результат, и принимают её обычно без вопросов.

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

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

В логе стояло ::ffff:192.0.2.5, в конфиге — 192.0.2.5. Что строки разные, видно сразу. Но выглядит это как разное написание одного адреса: справа те же четыре октета, слева приписка, которую принимаешь за особенность формата. Поэтому проверять я пошёл конфиг, а не сравнение.

Строчка, которая встречается в скриптах повсеместно:

mysql -u admin -pSecretPass123 -e "select 1"

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

Формулировка встречается в политиках конфиденциальности постоянно и звучит успокаивающе. На деле она означает одно из двух: либо в компании действительно шифруют пароли — и это плохо, — либо там не различают шифрование и хеширование, что тоже не добавляет уверенности.

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

Ситуация обычная: пришёл запрос на удаление персональных данных, разработчик выполнил DELETE FROM clients WHERE id = ..., отчитался. Формально всё правильно — строки в таблице нет, приложение её не видит, выгрузка не содержит.

А в файле базы она есть. Целиком, вместе с именем и номером карты, и достаётся обычным grep.

Обычная логика такая: не хочу, чтобы меня узнавали — открываю приватное окно, и всё, я новый посетитель. Логика была верной примерно до середины десятых годов.

Сейчас узнавание держится не на cookie, а на наборе свойств самого браузера. Их не надо никуда сохранять — они просто есть, и по их сочетанию посетитель определяется с высокой надёжностью. Очистка хранилища на это не влияет никак: удалять там нечего.

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

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

Про публичный Wi-Fi принято говорить одно из двух. Либо «там воруют пароли, не подключайтесь», либо «сейчас везде HTTPS, всё в порядке». Обе формулировки неточные, и обе мешают понимать, что происходит на самом деле.

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