В контексте работы с доступами, да и с точки зрения массового сканирования сети Интернет в исследовательских целях, часто возникает проблема получения "абуз" в виду нарушения ToS (Terms of Service) хостингов. Предлагаю разобрать, почему приходят "абузы", какие бывают, как с ними бороться и как минимизировать потери.
Итак, типичный пользователь заказывает VDS/VPS/Dedicated Server/... с какой-либо ОС, устанавливает туда masscan, zmap или какое-нибудь старье вроде scanrand, unicornscan. После запуска сканирования в скором времени (от нескольких часов до нескольких дней) приходит письмо от тех. поддержки, либо учетная запись/арендованный сервер блокируются.
Начнем с причин. Большинство жалоб являются следствием быстрого сканирования подсетей какого-либо крупного владельца. Чаще всего, как показывает практика, Hetzner и некоторых .edu-учреждений. Скорость сканирования действительно может сильно влиять на полезное время функционирования сканирующей машины, но чудес ждать не стоит, да и обычно стоит цель просканировать как можно быстрее. Приходящие жалобы являются автоматизированными, т.е. в исключительно редких случаях жалобу составляет реальный человек, обычно сетевое оборудование просто видит аномальную с его точки зрения активность, получает информацию об IP-адресе из WHOIS, оттуда же берется адрес, куда слать "абузы", далее формируется e-mail и отправляется по указанному адресу.
Ниже приведены примеры "абуз" от Hetzner, .edu-учреждений, Российской Netis-Telecom и нескольких других сетей:
Как видно из текста, это и правда автоматически сформированные письма. Письма от технической поддержки или системных администраторов на практике большая редкость на фоне автоматических рассылок. Если бы только люди писали такие письма, то сканирование с одного хоста можно было вести неделю или больше, причем вне зависимости от хостера.
Что можно сделать, если вам пришло письмо от тех. поддержки, а продлить срок работы необходимо? Естественно, вступить в диалог. В большинстве случаев подойдут шаблонные ответы, например:
Hello,
Sorry for the inconvenience, one of my droplets is just port scanning for several ports large IP ranges to provide info for my research regarding network statistics (like info that can be obtained from Shodan). The scan won't last long and will be shut down in 24 hours. It won't cause any network malfunction for other systems, I just need to obtain some info to provide some sort of statistics in my paper.
Hello,
Recently I have created a droplet that is doing a minor network scanning in academic purposes.
Sorry, if it was against ToS. I've already shut down the scanning process.
Thank you.
Это позволит выиграть немного времени, чтобы забрать данные или завершить сканирование в некоторых случаях. Можно растягивать и отвечать с большими интервалами, но так или иначе хост будет заблокирован. Похожие ответы можно также использовать, чтобы добиться разблокировки на время и забрать результаты сканирования.
Что можно сделать чтобы избежать блокировок или максимально растянуть их во времени? Во-первых, выбор хостера. Ниже приведена небольшая сводная таблица по стоимости и блокировкам:
Aruba Cloud - www.arubacloud.com - 1€/мес - 2-7 дней - блокировка аккаунта без писем от саппорта
Digital Ocean - www.digitalocean.com - 5$/мес - 1-2 дня - приходят письма от саппорта, можно выиграть немного времени диалогами
Servers.com - www.servers.com - 5€/мес - 7+ дней - письма не приходили, блокировки не было
Microsoft Azure - azure.microsoft.com - free - 1-30+ дней - письма приходят, но есть нюансы
EstNOC - www.estnoc.ee - 5$/мес - 2-5 дней - приходят письма от саппорта
Для сканирования использовались самые дешевые VPS, на них запускался masscan со следующими параметрами:
|
1 |
masscan 0.0.0.0/0 -p3389 --max-rate 100000 -oL scan.txt --exclude 255.255.255.255 |
Уточню детали по поводу бесплатности Microsoft Azure. Многие знают, что существует программа Microsoft BizSpark (https://www.microsoft.com/ru-ru/ms-start), в рамках нее предоставляется доступ к куче лицензионного ПО и 150$ в месяц на Microsoft Azure в течение года. Податься на нее довольно легко, достаточно сделать лендинг, описывающий ваш стартап (можно скопировать чей-нибудь) и отправить заявку. Также есть вариант взять тестовый месяц https://azure.microsoft.com/ru-ru/free/ но я не пробовал.
Вернемся к избеганию блокировок. Также могут влиять настройки сканирования, точнее они однозначно влияют, но зависимость хитрая. Разберу на примере того же Azure: в качестве теста было сделано 5 аккаунтов, на каждом по 2 виртуальные машины. При неагрессивном сканировании (--max-rate 4000, на один порт, плюс перерывы в сканировании в районе суток, т.е. непрерывное сканирование велось буквально несколько дней, потом делался перерыв) виртуальные машины прожили в районе месяца, никаких претензий не приходило. Далее была увеличена скорость (--max-rate 8000, 4-6 портов, без перерывов) и в пределах нескольких дней пришло письмо:
Но это отвалился один аккаунт, виртуальные машины на других продолжают без проблем сканировать, никаких писем не приходит. Вообще скорость незначительная на фоне тестовой скорости, которая упоминалась выше, но такая вот ситуация. Возможно стоит модифицировать логику работы masscan с диапазонами или просто аккуратно их делить перед выгрузкой на сканирующие хосты, чтобы с одной машины проходились как можно меньшие диапазоны в рамках одной сети. Ниже приведу скрипт на Python, который разбивает диапазоны в CIDR нотации (это когда 10.11.12.13/24):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 |
def get_ip_ranges(ip_list, N): import ipaddress get_ip_range_size = lambda ip: 2 ** (32 - int(ip.strip().split('/')[1])) dic = {} total_size = 0 for line in ip_list.strip().split('\n'): dic[line] = get_ip_range_size(line) total_size += dic[line] n_size, r = divmod(total_size, N) n_sizes = [] for i in range(N): app = 0 if r > 0: app = 1 r -= 1 n_sizes.append(n_size + app) targets = {} parts = [] for i,sz in enumerate(n_sizes): loc_size = sz targets[i] = [] while loc_size > 0: if dic.keys(): key = list(dic.keys())[0] range_size = dic[key] if range_size <= loc_size: loc_size -= range_size targets[i].append((key,0,range_size)) del dic[key] else: targets[i].append((key,0,loc_size)) del dic[key] parts.append( (key,loc_size, range_size-loc_size) ) loc_size = 0 else: key, start, end = parts.pop(0) if end <= loc_size: loc_size -= end targets[i].append((key,start,end)) else: targets[i].append((key,start,loc_size)) parts.append( (key,start+loc_size, end - loc_size) ) loc_size = 0 result = [] for k,v in targets.items(): result.append([]) for range_ip in v: ip_init = range_ip[0].split('/')[0] start = int(ipaddress.IPv4Address(ip_init)) + range_ip[1] end = start + range_ip[2] - 1 result[-1].append('%s-%s'%(str(ipaddress.IPv4Address(start)),str(ipaddress.IPv4Address(end)))) return result ip_list = '' with open('all.txt', 'r') as ifh: ip_list = ifh.read() N = 5 ranges = get_ip_ranges(ip_list, N) # print(ranges) for proc in ranges: with open('include_' + str(N) + '.txt', 'w') as ofh: for ip in proc: ofh.write(ip + "\n") N = N - 1 |
Необходимо использовать Python3, N = 5 - количество частей, на которые делятся все диапазоны из файлы. В результате получаем N файлов с именами вида include_*.txt, которые можно загружать на хосты для сканирования.
Подведем итог по способам предотвращения жалоб и увеличения продолжительности жизни хостов: грамотный выбор хостера, не слишком высокие скорости сканирования, распределение сканирования больших подсетей одного владельца на несколько хостов.
Не забываем, что в идеале стоит выгружать результаты сканирования, например, каждый час на отдельный сервер, чтобы в случае потери не пришлось заново проводить сканирование всего диапазона, который сканировала машина. На уровне костылей это тривиально автоматизируется Bash-скриптом на десяток строк, менее тривиально - написать нормальный скрипт на каком-либо языке, а данные хранить в MongoDB, хотя можно и в MySQL или PostgreSQL, зависит от ваших амбиций по сканированию.
Вот и все? Не совсем, есть еще один вариант, который редко рассматривается и является затратным, но может для кого-нибудь окажется целесообразным. Итак, можно еще попробовать для быстрого сканирования и возможности 100% не потерять результат, поступить следующим образом: приобретается свое оборудование, ставится в стойку, приобретается пул IP-адресов, приобретается доступ к какой-либо точке обмена трафиком (IX), далее вам потребуется у кого-то взять "доступ" в остальной интернет (внешний канал). Ваша подсеть является "тупиковой AS", вы начинаете сканировать "весь интернет". Что произойдет дальше? Для начала вам, как владельцу начнут приходить жалобы, вы их можете игнорировать или формировать шаблонные ответы, что меры приняты. Это поможет вам на условный месяц, к этому времени уже могут появиться запросы от людей, которым можно некоторое время объяснять, что решаете проблему, приняты меры и т.п.
Далее возможны несколько вариантов:
1. Ваша подсеть молча блокируется тем же Hetzner и все;
2. Абузы начинают приходить вашему аплинку (тому, кто вам предоставляет доступ, например, с MSX-IX в глобальную сеть).
Любой аплинк не заинтересован, чтобы его диапазоны попали в черный список крупных сетей, поэтому уже с его стороны будет обращение в ваш адрес, где можно будет потянуть время, но в конечном счете вам откажут в обслуживании (при условии, что за вас кто-то серьезно взялся). Можно повертеться, внести изменения в так называемый routing object, взять другой аплинк, но выбор не велик, точнее велик, но не настолько. Также происходит обмен информацией и вы запросто можете попасть в черный список и трафик с вашего диапазона порежут с помощью ACL, что даже в пределах IX никуда пойти не удастся. Сроки? Сроки могут быть разные, зависит от того, насколько серьезно кто-то возьмется за ваши сканирования.
Кто-то спросит, а зачем это все, ведь есть "абузоустойчивые" хостеры. Да, есть, но в некоторых ситуациях удобнее и дешевле опираться на собственное железо, чем платить кому-то крупную сумму за аренду и не иметь контроля над оборудованием.
Подводя итог, можно сказать, что достаточное быстрое и продуктивное сканирование возможно организовать:
1. С использованием множества дешевых VPS, которые потребуют автоматизации создания инстансов, выгрузки/загрузки информации и агрегации всего на стороннем сервере.
2. Одиночным сервером с действительно широким каналом и собственной IP-подсетью, что даст возможность точно знать, приходят ли "абузы", от кого, и позволит гибко на них реагировать, а также всегда будет возможность забрать результат работы.
3. По смыслу второй пункт, но обратиться к "абузоустойчивым" хостерам, вместо того, чтобы самостоятельно все организовывать.
Что выбрать? Решать вам.
Первоначально статья была размещена 9.11.2017 на форуме exploit.in.
И сколько тебе платят за эти внешние ссылки?
Нисколько. Просто опубликовал ссылку на свою статью, чтобы не копировать контент
На OVH никаких блокировок при --max-rate 100000.
Зависит от канала сервера и их мониторинга, который сообщает об аномалиях в сети и, в частности, на порту твоего сервера. Иногда на портах коммутаторов стоят рейт лимиты, которые если превысить, можно получить щелбан предупреждения от службы мониторинга.
На гигабитном канале рейт лимит выше чем на 100мбит порту, соответственно и брутить можно яростнее.
Для статистики. Хостер Scaleway.
Сканирование было 4000-5000 на 1-6 портов по России. Но там не долго, час-два, семь. Все ок.
Затем запустил скан европы на 10000 потоков , 6 портов, заблокировали на 4 или 5 день.
Абуза:
"ood afternoon,
Your Ip address (xxx.xxx.xx) is actually listed on UCEPROTECT
You can check it with the form available on their website : http://www.uceprotect.net/en/rblcheck.php
Thank you to take the necessary action to stop all the spam sending as soon as possible.
Feel free to contact Online.net technical assistance for more information
Online.net Abuse service"