Всё-таки как можно переставить всё с ног на голову… Прочитал сегодня статью на CNews.com; она небольшая, привожу полностью:

Исследователь безопасности разработал сайт, наглядно демонстрирующий риск, с которым сталкиваются пользователи Windows при использовании браузера Safari от Apple.

ИБ-команда Microsoft уже предупредила, что «смешанная угроза» настолько серьезна, что пользователям Windows следует ограничить использование Safari до тех пор, пока не выйдет патч. В своем блоге исследователь Лю Ди Ю (Liu Die Yu) показал, что это предупреждение не было преувеличением.

При клике по указанной исследователем ссылке в Safari с настройками по умолчанию на рабочий стол пользователя Windows загружается файл-ловушка. В следующий раз, когда пользователь открывает Internet Explorer, файл автоматически запускает notepad.exe и открывает несуществующий файл. Разумеется, злоумышленники могут найти менее безобидное применение данной уязвимости, пишет The Register.

По словам Apple, уязвимость не является критической. Эта демонстрация свидетельствует об обратном.

Читать статью «Доказана критичность уязвимости в Safari для Windows» полностью…

Устав от того, что ко мне на компьютер ломятся всякие придурки юные кулхацкеры, я решил принять меры.

Товарищи кулхацкеры лезут в систему с трёх сторон:

1. Путем подбора пароля на SSH.
2. Путем подбора пароля на FTP.
3. Пытаясь использовать компьютер в качестве релея (это уже спамеры).

Есть и другие поползновения (например, попытки достучаться до MySQL, к которому снаружи добраться в принципе невозможно; или пытаясь навести "злобные пинги"), но три вышеописанных метода меня раздражают больше всего.

Стратегия защиты: Читать статью «Скажи “Нет!” взломщику» полностью…

Разбираясь с деталями реализации распределителей памяти (allocator) в C++, я решил вспомнить своё криптографическое прошлое Не в том плане, что я эксперт в криптографии, а в том, что приходилось читать соответствующую литературу (до сих порэтот гигабайт на винте валяется), разбираться с ней, анализировать алгоритмы, оценивать их с точки зрения безопасности и в том же духе. Но это не важно. Разбираясь с деталями реализации, я вспомнил интересную статью Питера Гутмана, "Secure Deletion of Data from Magnetic and Solid-State Memory". Еще в то время, когда я этим всем активно занимался и читал, мне в голову прочно врезалась фраза, смысл которой сводился к тому, что очень немногие криптографические библиотеки действительно заботятся о конфиденциальности чувствительной информации (например, ключи шифрования). Ведь информацию можно "вытащить" и из памяти выключенного компьютера; или с жесткого диска, даже если информация была переписана. Всех, кому интересна практическая реализация восстановления информации, отсылаю к статье Питера Гутмана (ссылка приведена выше).

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

Анализируя журнал безопасности системы, я добавляю в iptables правила, блокирующие доступ с адресов, с которых замечены попытки вторжения. В большинстве случаев в черный список попадают товарищи, пытающиеся залезть в систему по SSH; иногда я добавляю злостных хакеров, пытающихся устроить DoS или проводящих SQL injection/сканирование на наличие уязвимостей (поиск таких вот товарищей приходится осуществлять вручную, ибо их методы очень различны, и автоматический анализатор, дающий хотя бы 85% гарантию обнаружения, я пока еще не написал).

В надежде, что этот список (оформленный в виде правил для iptables) окажется кому-нибудь полезным (он будет периодически обновляться), выкладываю его в общее пользование. Читать статью «Список адресов, с которых осуществляются попытки вторжения в систему» полностью…

FCrDNS, или Forward Confirmed Reverse DNS, это когда IP-адрес имеет прямую (имя -> IP) и обратную (IP -> имя) DNS-записи, которые, к тому же, соответствуют друг другу.

Сначала выполняется обратный DNS-запрос для получения списка PTR-записей (обычно возвращается только одна запись, но это не всегда так). Затем для каждого доменного имени, указанного в PTR-записях, выполняется обычный (прямой) DNS-запрос с целью проверки, что существует запись A или AAAA, совпадающая с исходным IP-адресом. Если это так, то проверка считается пройденной.

Проверка FCrDNS может считаться слабой формой аутентификации, устанавливающей, что есть действительная связь между владельцем доменного имени и владельцем сети, получившим данный IP-адрес. Хотя такая аутентификация и слаба, она достаточно хороша, для того, чтобы отсеивать спамеров и иже с ними, использующих компьютеры-зобми для подделки доменов.

Перевод Forward Confirmed reverse DNS.

А теперь о практической реализации. Читать статью «Forward Confirmed reverse DNS, или, Зомби не пройдут» полностью…

Как-то на досуге я занялся анализом приходящего спама и обратил внимание, что практически 98% спама в комментариях приходят с IP-адресов, замеченных в рассылке спама по электронной почте. А спамеры обычно попадают в черные списки (blacklist).

DNSBL — DNS blacklist или DNS blocklist — списки хостов, хранимые с использованием системы архитектуры DNS. Обычно используются для борьбы со спамом. Почтовый сервер обращается к DNSBL, и проверят в нём наличие IP-адреса клиента, с которого он принимает сообщение. При положительном ответе считается, что происходит попытка приёма спам-сообщения, и оно блокируется (не принимается сервером, и, как правило, отправителю отсылается уведомление об этом).

Идея состоит в том, чтобы написать расширение для WordPress, проверяющее наличие IP-адреса комментатора в чёрном списке. Читать статью «Использование DNSBL для борьбы со спамом в комментариях» полностью…

Как известно, в целях безопасности сервер MySQL по умолчанию открыт для доступа только с локальной системы. Поэтому, когда на сервере не установлен PhpMyAdmin, а консольной версией клиента пользоваться просто неудобно (ненаглядно), приходится открывать доступ для удаленного пользователя. Но такое решение не самое безопасное.

В таких случаях рекомендуется использовать методику, имеющую название port forwarding (перенаправление портов). Читать статью «Доступ к удалённому MySQL-серверу по SSH» полностью…

Криптографический протокол Диффи–Хеллмана (Diffie-Hellman Key Exchange) — алгоритм, позволяющий двум сторонам получить общий секретный ключ, используя частично защищенный канал связи. Под частично защищенным понимается канал, данные в котором защищены от модификации, но не от прослушивания (как утверждает Wikipedia, такие условия имеют место довольно часто).

В данной статье я приведу реализацию криптографического протокола Диффи-Хеллмана на языке С с использованием библиотеки GMP. Читать статью «Реализация криптографического протокола Диффи-Хеллмана обмена ключами с использованием GMP» полностью…

Да, день сегодня явно прожит не зря…

Сообщая службе технической поддержки oDesk о небольшой ошибке в WorkDiary 2.0 Beta, я обратил внимание на одну особенность их системы (пока oDesk не отреагирует, я не могу сказать, на какую). Это толкнуло меня на эксперимент. В результате я нашёл две довольно-таки неприятные уязвимости (когда oDesk их исправит, я о них расскажу). Опять же, эти уязвимости существуют из-за недостаточной обработки входных данных и излишнего доверия пользователю.

Повторюсь еще раз (ибо repetitio est mater studiorum): данным, пришедшим из внешнего источника (например, от пользователя), доверять нельзя!

Почему-то каждый третий мнит себя экспертом по безопасности, пишет "безопасные" программы для шифрования данных, но даже не подозревает, что существуют и другие режимы шифрования, кроме известного как ECB. И этим грешат не только студенты в своих дипломных работах (головы бы поотрывал их научрукам за такое), но и "серьёзные" разработчики.

Например, программист на сайте uk-swingers.com шифровал номера кредитных карточек (!), используя простой алгоритм RC4 и постоянный ключ. Ломалось очень просто. К счастью, уже исправлено Другие товарищи использовали сложение по модулю два для шифрования важных данных. Третий товарищ защитил диплом по безопасности, и шифрование секретной базы данных опять-таки выполнялось по модулю два. Четвертый шифровал AES'ом тонны информации (в режиме ECB, разумеется), при этом не потрудившись даже ее сжать. Этот печальный список можно продолжать и продолжать…

Я решил провести наглядный эксперимент, чтобы выяснить, насколько эффективны различные алгоритмы шифрования в различных режимах работы. Читать статью «Режимы шифрования данных, или, когда сильный шифр не спасает» полностью…

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