Менеджер домена CO.CC опубликовал обращение к Google

Менеджер домена CO.CC опубликовал обращение к Google

Некоторое время назад Google приняла решение полностью исключить из выдачи своей поисковой системы все узлы, расположенные в домене второго уровня CO.CC. Аналитикам компании показалось, что в этой зоне размещены сплошь вредоносные и фишинговые ресурсы. И вот последовала реакция "обвиняемых": сегодня на форуме Google для веб-мастеров появилось сообщение от имени главного управляющего этим доменом Джеймса Кима.


Обычно генеральные менеджеры не пишут форумных сообщений, однако г-н Ким, по его словам, так и не смог добиться никакого официального ответа от руководства Google и в силу этого был вынужден опубликовать свое обращение, придав ему тем самым вид открытого письма. Впрочем, следует помнить, что теоретически выдать себя за координатора домена мог кто угодно: пока что нет данных, которые позволили бы однозначно установить связь между г-ном Кимом и учетной записью "JamesKim" на форумах Google.

В сообщении заявляется, что решение о деиндексировании домена CO.CC непропорционально: в нем зарегистрировано более 10 млн. имен, среди которых "доля вредоносных не превышает 0,01%". Кроме того, по мнению автора сообщения, перед исключением из выдачи такого количества информационных ресурсов (по приведенной оценке, в CO.CC расположено более 200 млн. уникальных страниц) Google могла бы потрудиться хотя бы направить в координационный центр домена соответствующее уведомление.

В целом нельзя сказать, что "JamesKim" совершенно неправ: Trend Micro, например, обнаруживает в проблемном домене всего 35 тыс. вредоносных и нежелательных URL. Конечно, это не 0,01%, но и оснований для обвинения в тотальной вредоносности не дает. Кроме того, автор отметил, что руководство домена активно сотрудничает с поставщиками защитных решений - с Symantec и той же Trend Micro, - взаимодействует с организацией Spamhaus и даже с ФБР США (по направлению ресурсов порнографического характера).

Реакция адресатов письма пока неизвестна. У пользователей форума Google "JamesKim" понимания также не нашел: основная масса комментаторов оказалась явно настроена против него. Условным союзником координаторов CO.CC можно считать разве что Trend Micro, которая ранее заявила в корпоративном блоге о бесполезности принятого поисковым гигантом решения.

Softpedia

Письмо автору

" />

Шифрование не делает VPN невидимым: как сети распознают защищённый трафик

Пользователь Хабра под ником mr_tom объяснил, почему зашифрованное VPN-соединение всё равно можно обнаружить и заблокировать. Содержимое туннеля остаётся недоступным наблюдателю, но само соединение продолжает оставлять вполне заметные следы. Система фильтрации может видеть IP-адрес сервера, порт, транспорт, особенности начала обмена, размеры пакетов, интервалы между ними и поведение потока во времени.

Прочитать переписку она не способна, зато определить, на что похож трафик, — вполне. Шифрование надевает на данные броню, но не выдаёт им плащ-невидимку.

Для простейшей блокировки DPI вообще не требуется: достаточно ограничить известный IP-адрес, подсеть, порт или транспорт. Более сложные системы анализируют сочетание признаков и формируют отпечаток — профиль характерных свойств соединения.

 

Дополнительным инструментом становится active probing. Если конечная точка кажется подозрительной, система сама подключается к серверу и изучает его ответ. Поэтому значение имеет не только поведение трафика пользователя, но и реакция серверной стороны на посторонние запросы.

Автор отдельно разбирает популярную связку VLESS, XHTTP и REALITY. Называть её тремя VPN-протоколами некорректно: компоненты работают на разных уровнях. VLESS задаёт логику взаимодействия клиента и сервера, XHTTP отвечает за транспорт, а REALITY — за защиту транспортного соединения и внешний TLS-профиль.

Использование порта 443 тоже не превращает любой VPN в обычный HTTPS. Классификатор может учитывать рукопожатие и последующее поведение потока, а не только номер порта.

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

RSS: Новости на портале Anti-Malware.ru