А что, нынче в моде DoSить торрент-клиенты?

[Bizdelnick]

Заглянул ненароком в dmesg и узрел:

Код: Выделить всё

[5345333.825312] UDP: bad checksum. From 91.214.247.253:63901 to 192.168.1.128:51413 ulen 28
[5345336.840398] UDP: bad checksum. From 91.214.247.253:63901 to 192.168.1.128:51413 ulen 28
[5346936.858709] UDP: bad checksum. From 91.214.247.253:64240 to 192.168.1.128:51413 ulen 28
[5346939.894940] UDP: bad checksum. From 91.214.247.253:64240 to 192.168.1.128:51413 ulen 28

Такого много, c 14 разных адресов. UDP-порт 51413 у меня слушает transmission. К чему бы это?

[MrClon]

Адреса из разных автономных зон? Вообще торрент клиенты логичнее дость мусором на уровне приложений, а не на уровне UDP.

[Bizdelnick]

Адреса из разных автономных зон?

Да.

Spoiler

46.63.225.70
46.116.24.45
46.116.75.141
46.116.103.152
46.117.170.226
82.209.86.46
85.64.242.225
85.234.56.22
89.138.202.16
89.138.208.167
89.138.229.108
91.214.247.253
109.186.15.108
212.143.227.246

[phantomSSL]

возможно вы поучаствовали в DNS Cache Poisoning от братского народа китая...

[Bizdelnick]

возможно вы поучаствовали в DNS Cache Poisoning

Это каким образом?

[phantomSSL]

да в раздачах вместо трекера указывают ip или хостнейм жертвы и мирные пользователя начинают ломиться не туда:

Код: Выделить всё

42.85.85.33 - - [16/Jan/2015:10:05:51 +0400] "GET /announce.php?info_hash=%E2%9B%D7%FAn%3B%E8%E8A%FDP%8E%DB%00%13%9A8U3%EB&peer_id=%2DSD0100%2DsS%B8%88i%A7%BA%DCj6%91%B2&
ip=42.85.85.33&port=10148&uploaded=862447643&downloaded=862447643&left=642252800&numwant=200&key=28930&compact=1 HTTP/1.0" 444 0 "-" "Bittorrent"

на паре клиентов наблюдал такое...

[Bizdelnick]

А причём тут DNS poisoning? И причём тут приходящие мне невалидные пакеты?
Но интересно, сообщения "Could not connect to tracker" в логе трансмиссии не оттуда ли? Кабы там хоть какая-то более вменяемая информация была...

[Hephaestus]

Bizdelnick, у Вас проблема с любыми трекерами или с каким-то конкретным?
Проявляется ли с другим клиентом?

Возможно, это бага transmisson. На рутрекере, к примеру, данный клиент не рекомендован к использованию вплоть до определенной версии. Точную причину не знаю, поскольку данным клиентом не пользуюсь.
Но вообще такая ситуация со многими клиентами. Запрещены все по разным причинам - от утечки пасскеев до нарушения статистики.
Когда я, в своё время, стал подбирать клиент, совместимый с рутрекером, единственным беспроблемным, из имеющихся в репах, оказался rtorrent. Не считая ktorrent, который отпадает в виду неиспользования KDE.

[Bizdelnick]

у Вас проблема с любыми трекерами или с каким-то конкретным?

У меня всё работает, в логах только невнятные сообщения. К чему они относятся — понять невозможно. И вопрос не в том, как что-то починить, благо ничего не ломалось, а в том, не пора ли готовиться к обороне на случай более серьёзных атак.

[phantomSSL]

А причём тут DNS poisoning? И причём тут приходящие мне невалидные пакеты?
Но интересно, сообщения "Could not connect to tracker" в логе трансмиссии не оттуда ли? Кабы там хоть какая-то более вменяемая информация была...

классификацией не я занимаюсь. пиратскую бухту используете?

[Bizdelnick]

пиратскую бухту используете?

Нет.

[Bizdelnick]

А вот это, похоже, может иметь непосредственное отношение к теме: https://www.us-cert.gov/ncas/alerts/TA14-017A

[MrClon]

Каким местом? Может я что-то недопонимаю, но ведь для таких атак амплификатору надо послать валидный UDP пакет с IP жертвы в качестве source IP. А тут сами UDP битые.

[Bizdelnick]

для таких атак амплификатору надо послать валидный UDP пакет с IP жертвы в качестве source IP

В теории — да. На практике — фиг его знает, не исключено, что с Божественным клиентом в Божественной ОС и такое прокатывает.

[Bizdelnick]

Ещё в дебажном логе клиента встречаются сообщения «Couldn't parse UDP tracker packet». Но вообще вся подозрительная активность очень низкая, так что на DoS не особо похоже.

[MrClon]

Ошибка намекает что пакеты до Божественного Клиента не доходят, дропаются при обработке ядром из-за неверной чексуммы. Детали того как ядро работает с UDP пакетами я не вкуривал, но это кажется наиболее вероятной гипотезой.
Что до Божественной ОС. Есть пакеты от атакующего собраны правильно то получатель, рассматривая 3 и 4 уровни OSI, никак не сможет определить подмену IP. Если пакет собран не правильно то его дропнет любая ОС с более-менее вменяемым сетевым стеком.
К тому-же даже не правильная подмена IP не должна сломать чексумму UDP датаграммы.
Неверная чексумма UDP пакетов не является свидетельством в пользу подмены source IP и следовательно не является свидетельством в пользу использования твоего компа в качестве амплификатора в DRDoS атаке.

[Bizdelnick]

Ошибка намекает что пакеты до Божественного Клиента не доходят

Так ведь у меня и клиент не Божественный, и ОС не Божественная.

Неверная чексумма UDP пакетов не является свидетельством в пользу подмены source IP и следовательно не является свидетельством в пользу использования твоего компа в качестве амплификатора в DRDoS атаке.

В принципе да. Но это свидетельство того, что происходит какая-то фигня. Есть более правдоподобные предположения?

[Bizdelnick]

Отловил wireshark'ом обмен пакетами с этим 91.214.247.253. По ходу, это всё-таки просто кривой клиент. Первый пакет ушёл с моей стороны, в ответ пришёл битый. Сразу же следом это повторилось. Потом пауза около минуты, и то же самое, только удалённый порт другой. Всего 10 пакетов от меня и 10 ответных.

[MrClon]

Скорее не клиент (UDP пакет собирает ядро,а не юзерспэйсовая программа вроде), скорее сеть глючит у того пира, пакеты по пути бьются. Если повреждение приходится на IP или L2 заголовки то пакеты до тебя просто не доходят (дропаются ближайшим роутером), а если на L4 датаграмму то они доходят до тебя и дропаются уже ядром.

[Bizdelnick]

100% битых пакетов из-за глюка сети? Такое бы быстро заметили и починили. Это какой-то более специфический баг, фиг его знает где конкретно.

[MrClon]

100% направленных тебе за время наблюдения (кстати как долго ты наблюдал?). Не обязательно в магистральной сети, может домашний роутер сбоит.
Может не сеть, а что-то в ОС (в ядре по идее).

[phantomSSL]

А вот это, похоже, может иметь непосредственное отношение к теме: https://www.us-cert.gov/ncas/alerts/TA14-017A

https://ru.wikipedia.org/wiki/DNS_cache_poisoning

атак амплификатору

про амплификейшен и разговора не было

[Bizdelnick]

https://ru.wikipedia.org/wiki/DNS_cache_poisoning

Я это читал, но так и не понял, каким боком тут сабж. Поясните.

[MrClon]

атак амплификатору

про амплификейшен и разговора не было

Было. Полюбопытствуй по ссылке:

А вот это, похоже, может иметь непосредственное отношение к теме: https://www.us-cert.gov/ncas/alerts/TA14-017A

https://ru.wikipedia.org/wiki/DNS_cache_poisoning

Я это читал, но так и не понял, каким боком тут сабж. Поясните.

Я тоже не понял.