Pull to refresh
27
0

User

Send message
А каким образом они могут их различать?


В общем случае их действительно никак не различить. Но это можно сделать детектировав присутствие антивируса (авторы это делают путем посылания тестового вируса). Кроме того авторы обнаружили, что размеры буферов чаще всего равняются 64, 128 и 256 KB, что очень типично для сетевых устройств, в то время как антивирус в принципе может иметь буфер гораздо большего размера. Ну и плюс, авторы для замера размера буфера посылали не HTTP пакеты по TCP, а UDP пакеты с мусором, так что веб-модуль тут не при чем.

Это чрезвычайно странно, потому что я сейчас сам проверил (через 208.67.220.220) — выдало www.l.google.com [74.125.87.104]


А возможно OpenDNS делают подмену только в США, чтобы народ это не замечал по локализованной странице. Кстати, авторы обнаружили, что помимо OpenDNS, такими подменами помимо OpenDNS балуется один из штатовских провайдеров.
Тут все в порядке. MTU 1500 байт — это максимум в Ethernet. 1492 байта тоже очень неплохо.
Если я правильно понимаю, чаще всего причина этого — включенный веб-модуль антивируса, который проходящую информацию кеширует и анализирует.


Нет, авторы имеют в виду физические буферы в модеме.

Тут ещё проще — когда DNS не находит имени для рессолва, в случае OpenDNS и некоторый провайдерских возвращается не стандартный ответ, а веб-страничка, у OpenDNS — с их поисковым движком.


Да, этот эффект имеет место, авторы называеют его NXDOMAIN wildcarding. Проблема в том, что некоторые приложения могут зависеть от корректного ответа на несуществующий домен в виде статуса NXDOMAIN. Кроме того, такая замена на свою страничку предполагает, что DNS запрос был послан браузером, который сможет в итоге отобразить полученную страничку. А что есть запрос послал не браузер, а другое приложение, не знающее ничего об http?

Кроме того, под «подменой результатов DNS запросов» я имел в виду именно это — подмену. Например OpenDNS при DNS запросе на имя www.google.com возвращает не адрес гугла, а адрес своего прокси. То есть все ваши запросы к гуглу будут идти через их прокси. Ну и плюс авторы обнаружили, что некоторые инфецированные машины в ответ на запрос windowsupdate.microsoft.com получают левый адрес, что избежать апдейтов.
В принципе, ничего страшного. Это они проверяют DNS резолверы на предмет подверженности DNS cache poisoning атакам. С google DNS провернуть такую атаку скорее всего будет не просто.
7 x NC KIA (children) — как я понимаю приписка в скобках была сделана самими американцами.
Вот еще идея. Было бы круто, если бы спецы в своей области (графика, сети, безопасность и т.д.) описывали интересные статьи, появляющиеся на научных конференциях. Дело в том, что лекции и учебные пособия — это основа, а исследовательские работы — это уже «передовая линия». Мне кажется многим было бы интересно узнать по-подробнее о таких работах.
А планируется какой-нибудь механизм оценки качества постов (карма, рейтинг, etc)? Что если я, ничего не понимая в теории игр, напишу пост о ее применении в моделировании механизмов противоборства DDOS атакам? Умных слов будет много, возможно даже будет прослеживаться какой-то смысл, но в целом из-за фактических ошибок пост может легко ввести читателя в заблуждение.
Просьба в следующий раз на графиках подписывать что отложено по осям — краткое описание и единицы измерения. Искать эту информацию в тексте крайне неудобно.
А вообще по горизонтали отложено количество знаков х1000, а по вертикали — количество комментариев.


Интересно, слабенькая корреляция все-таки есть. В правой части графика значения по оси Y выше, т.е. грубо говоря, чем длинне текст, тем больше комментариев.
Тут я к сожалению не могу вам помочь, т.к. я не знаком с инструментом которым вы пользуетесь. Если эти графики (кстати, они называются гистограммы — histograms) рисуются при помощи какой-нибудь функции типа histogram(data), то можно попробовать просто histogram(log10(data)) или что-нибудь в этом роде.
Вот пример двух графиков для тех же самых данных. Обратите внимание на шаги по оси X на втором графике — они не линейные, а логарифмические. На втором графике видно, что основная часть данных лежит в интервале от 0.01 до 100. На первом графике этого разглядеть невозможно. Поэтому я и советую вам использовать логарифмические графики в тех двух случаях — они будут гораздо лучше читаться.

Пара комментариев по оформлению графиков. У вас практически нигде нет рисок с подписями на осях. Например на графике «Длина заголовка в символах» нужно по оси X проставить риски через каждые 10 или 20 единиц. Аналогично из графика «По дням недели» понятно лишь что в среду чуть больше записей чем, например, во вторник. Если вы по оси Y проставите риски со значениями, то сразу станет понятно, сколько же в среду публикуется записей.

Если вы собираетесь продолжить анализ, то предлагаю вам углубиться в изучение данных. То что вы представили это как бы описание основных параметров данных, из этого как правило не получается сделать интересные выводы. Все станет гораздо интереснее если вы найдете какие-нибудь неожиданные корреляции. Например верна ли гипотеза, что чем длиннее заголовок, тем больше комментариев? Или влияет ли объем текста на колличество комментариев? Эти утверждения я привожу здесь лишь в качестве примера. Как мне кажется вы попытались сделать что-то в этом роде на последнем графике, но я его, если честно, не понял. Чему соответствуют оси (еще раз возвращаемся к вопросу об оформлении осей)?
На этих графиках просто слишком «тыжелый хвост». В таких случаях нужно сделать ось X логарифмической, это как бы «растянет» данные по графику и сделает его более читаемым. Если нужно, могу показать пример с теми же данными на простом графике и на графике с логарифмической осью X.
Ну а изучить и модифицировать такую библиотеку не сложнее чем TCP/IP стэк в ядре, поскольку они делают фактически тоже самое.
Верно, если знать куда смотреть, то проблемы нету. Весь смысл метода и заключается в том, чтобы скрыть тайную пересылку в куче пакетов и соединений.
Ну, в принципе можно попытаться это сделать и так, но несовсем понятно как именно. Вам тогда придется все TCP соединение реализовывать при помощи raw-сокетов. Потому что в противном случае вы не будете знать когда именно посылать «тайный» пакет. Он же не наобум посылается, а когда приниматель просит это.
Все верно, вопрос тут в том куда смотреть. Если у вас в секунду более 1000 TCP соединений в каждом из которых по 1000 пакетов, то Wireshark тут не помощник — в ручную перелопатить такой объем данных нереально.
Имеется в виду изменение стэка не для перехвата и анализа, а для реализации самого метода.
Подобный вопрос уже был выше, под ним и ответ. Повторюсь, во-первых можно пытаться скрыть факт передачи тайной информации. Тогда факт наличия соединения не играет роли — мы не пытаемся его скрыть. Во-вторых если все-таки нежелательно чтобы вообще знали о факте хоть какой-нибудь передачи, то как я писал выше, отправитель и получатель «нормальных» данных может вообще и не знать о факте тайной переписки.
Возможно, хотя мне кажется, что предложение «The term packet is used generically here to mean the data of one transaction between a host and its network» можно понимать и по-другому. А если точнее, то «transaction», как мне кажется — это акт единичной передачи порции данных, т.е. фактически один пакет. Хотя даже если я заблуждаюсь, то с 1981 года многое молго измениться и сейчас, я совершенно уверен, употребляют выражение «TCP пакет».

Information

Rating
Does not participate
Registered
Activity