Хостинг [Прокладка и основной хост C2] абузы, срок жизни, защита

[montanaboy]

Доброго времени суток! Хотел поразмышлять по поводу вопросов из заголовка темы, поделиться своими мыслями, получить критику и советы.
Схема следующая:
Есть с2, установленный на основном хосте. Хост запрятан за прокладкой, прокладка стоит за CF (усложнить получение ip прокладки, базовая защита от ddos). На хосте запрет на коннект с любых ip кроме прокладки. Определить, что это "именно тот" сервер в обход прокладки невозможно.
Давайте подумаем, как будут уничтожать эту цепочку и искать основной хост. И как этому противодействовать.
Сначала торчит ip клауда, могут кидать репорты как в CF, так и на регистратора доменного имени. В зависимости от того, кто отреагирует первым, либо отзовут домен, либо забанят акк CF. В любом случае придется регистрировать новое доменное имя, клауд не даст использовать домен на который ему уже кинули репорт. На этом этапе мы теряем только доменное имя, сама прокладка (VPS) продолжает существовать на своем ip, о котором пока никто не знает. Вопрос - могут ли органы запросить у CF ip прокладки, на который он пересылал все запросы? Если нет, прокладки жили бы вечно, но это не так. Вывод - добраться до ip прокладки могут.
Если есть ip, могут либо направить репорт или официальный запрос. Тут будет зависеть от хостера, как долго будут тянуть резину и предупредят ли заранее. В худшем случае минус прокладка, ip основного хоста остается в тайне.
А могут конфисковать VPS с полным доступом ко всему что там было. Вот это интересно как часто происходит? В этом случае из конфигов реверс-прокси вытянут ip основного хоста, дальше в зависимости от провайдера нас либо предупредят и будет время сделать бэкапы, либо отрубят сервер с концами без лишних разговоров.

Исходя из рамышлений выше сложилась следующая картинка:
Имеет смысл регистрировать прокладки на "оффшорных/абузоустойчивых" серверах, которые будут тянуть резину при репортах, и заранее сообщать о проблемах. Если начался кипишь на прокладке, ее желательно в кратчайшие сроки заменить, а на старом VPS потереть все данные (на случай конфискации с полным доступом).
Напротив, основной хост нет смысла хостить на "оффшорных/абузоустойчивых" серверах, если прокладку конфискуют ip сервера будет известен. Даже если он абузоустойчивый, его прикроют через время так же как прокладку. Из плюсов можно выиграть немного времени и сделать бэкапы. Минусы хостинга на "оффшорных/абузоустойчивых" серверах перевешивают плюсы, потому как один из участников форума уже выражался тут:

Если бы я был оперативником, первым делом рекламировал бы сервис здесь под видом максимально темной личности. Абузоустойчивый с оплатой в крипте.

Сомнительно доверять ценные данные тому, кто знает что именно он хостит, белые хостеры определенно имеют меньший интерес поковыряться в ваших файлах, как минимум они не уверены на 100%, что там есть чем поживиться в их личных интересах.
Если все же решаемся хостить основу на абузоустойчивом сервере, то хотя бы не на том же хостинге, где прокладку. Будет чуть больше времени в случае облавы.
Плюсом, если на основном хосте есть ценные данные, надо иметь запасной сервер с бэкапами, и делать их регулярно, хотя бы раз в сутки. Думаю, даже если основному серверу пришел конец, сервер с бэкапами грохнуть так быстро не получится.

 

[montanaboy]

Подниму, а то актива вообще 0, ни привета ни совета

 

[hydrator]

клауд не даст использовать домен на который ему уже кинули репорт

На новый аккаунт добавляешь и все.

 

[montanaboy]

На новый аккаунт добавляешь и все.

То есть у клауда нет внутреннего блеклиста на доменные имена или ip адреса, на которые в поддержку клауда накидали жалоб и именно по этой причине акк забанили/удалили? Это проверенная информация или предположение ?

 

[7teen]

То есть у клауда нет внутреннего блеклиста на доменные имена или ip адреса, на которые в поддержку клауда накидали жалоб и именно по этой причине акк забанили/удалили?

Есть, домен они блокируют и его добавить уже будет невозможно никогда в клоуде ни на 1 аккаунт, даже если домен будет разделигирован и удален, по новой не выйдет.

Тобой описанная схема норм (ну почти), осталось только усложить туннели и сделать двойную-тройную прокладку, чтобы в момент падения самой первой прокладки на входе знать что какая-то х#йня происходит и снести вторую прокладку за ней и третью на всякий.


Чтобы домены не сносили, надо делать нормальный сайт на wordpress и путь по типу /loginbyadmin адрес для общения софта. Чтобы хостеру было неочевидным за что блок, если там просто сайт вордпресса.
CF сливает данные по запросу сто процентов, инфа достоверная.

 

[montanaboy]

двойную-тройную прокладку, чтобы в момент падения самой первой прокладки на входе знать что какая-то х#йня происходит и снести вторую прокладку за ней и третью на всякий

Не будет ли больших задержек и повышения шансов сетевых ошибок, таймаутов, потеряных пакетов/запросов/ответов ? Понятно, все ошибки софт должен корректно обрабатывать, но они могут сыпаться очень часто и это будет мешать работе. Предположу, задержки будут, потому что регать цепочки прокладок есть смысл только у разных хостеров = разное гео. У одного хостить бессмысленно, так как если упадет первая, за ней и все остальные, все равно что одна прокладка.

путь по типу /loginbyadmin адрес для общения софта

Как смотришь на имитацию RestAPI запросов на апи эндпоинт? Там есть где разгуляться, данные могут быть любыми. Рядом конечно хорошо иметь формочку входа, которая по этому апи будет работать, или имитировать работу.

 

[hydrator]

Есть, домен они блокируют и его добавить уже будет невозможно никогда в клоуде ни на 1 аккаунт, даже если домен будет разделигирован и удален, по новой не выйдет.

Тобой описанная схема норм (ну почти), осталось только усложить туннели и сделать двойную-тройную прокладку, чтобы в момент падения самой первой прокладки на входе знать что какая-то х#йня происходит и снести вторую прокладку за ней и третью на всякий.


Чтобы домены не сносили, надо делать нормальный сайт на wordpress и путь по типу /loginbyadmin адрес для общения софта. Чтобы хостеру было неочевидным за что блок, если там просто сайт вордпресса.
CF сливает данные по запросу сто процентов, инфа достоверная.

Интересно как я тогда заблокированные домены на другие аккаунты привязываю....

 

[hydrator]

То есть у клауда нет внутреннего блеклиста на доменные имена или ip адреса, на которые в поддержку клауда накидали жалоб и именно по этой причине акк забанили/удалили? Это проверенная информация или предположение ?

У них домен блокируется только если платная подписка не оплачивается на предыдущем аккаунте

 

[ordinaria1]

о котором пока никто не знает

После репорта в CF абуза сразу летит хостеру, обычно после этого блочат и впс.

Вопрос - могут ли органы запросить у CF ip прокладки, на который он пересылал все запросы?

Могут, но аверы и ресёрчеры порепортят, забанят всё быстрее.

Имеет смысл регистрировать прокладки на "оффшорных/абузоустойчивых" серверах, которые будут тянуть резину при репортах, и заранее сообщать о проблемах.

Определённо стоит брать сервера у адекватных хостеров. Таблица хостеров, составленная мармеладом, есть в закрепе. "Абузоустойчивые" можно взять на торговой площадке. Подобная таблица есть и для регистраторов, тоже в закрепе.

Лучшим вариантом будет реализовать подтягивание актуальных адресов через блокчейн. Блокчейн не забанишь, а адреса можно поменять. Примеры: [1], [2].

В любом случае придется регистрировать новое доменное имя, клауд не даст использовать домен на который ему уже кинули репорт

Можно использовать и другой CDN, если домен ещё не забанили и не пофлагали. Менять домен с одного акка на другой вроде как можно, и при этом пропадает уведомление. Но тут если не успел вовремя - домен весь в детектах от аверов.

 

[holynet]

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

 

[Dread Pirate Roberts]

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

почему именно гре?

 

[holynet]

почему именно гре?

А какой ты ещё туннель хочешь протягивать? Гре самый удобный и практичный на мой взгляд.
Может ты подскажешь идею получше)

 

[nixz]

А какой ты ещё туннель хочешь протягивать? Гре самый удобный и практичный на мой взгляд.
Может ты подскажешь идею получше)

Ну да любой туннель, стунель/опенвпн/вайргард, хоть ссш?
Хотели услышать очевидные плюсы перед поднятием других тунелей кроме субъективных ощущений.

 

[Dread Pirate Roberts]

А какой ты ещё туннель хочешь протягивать? Гре самый удобный и практичный на мой взгляд.
Может ты подскажешь идею получше)

поддерживаю предыдущего оратора, имхо любой впн или туннель подойдёт, непонятно, почему надо использовать именно гре.

 

[montanaboy]

Тебе нужно скрывать свой c2 если это коба то нужно ее кастомить иначе тебя аверы по заголвкам http найдут да и не только

Не коба, с заголовками не проблема, они подконтрольны

и нахуй твой cf не поможет так как vps все равно висит в инете и ее видно ну если только ты не закрыл ее за vpn сетью и не пустил траф через проксю

у cf естьтакие полезные эндпоинты

https://www.cloudflare.com/ips-v4/#

https://www.cloudflare.com/ips-v6/#

Ставим на свой vps файрволл, пишем .sh который через curl получает с указанных выше ссылок диапазоны ip и добавляет их в исключения файрволла (вайтлист), остальное блок. Делам задачу в крон на запуск скрипта раз в час.
В итоге имеем vps который не видно и подключиться к нему можно только через cf и вайтлист постоянно обновляется. Сервер будет пинговаться и в целом будет понятно, что там что-то есть, но что это конкретно - неясно. Запросы напрямую к vps будут отклонятся.

 

[adelona]

поддерживаю предыдущего оратора, имхо любой впн или туннель подойдёт, непонятно, почему надо использовать именно гре.

GRE выходит более универсальным решением, поддержка любого типа ip-трафика(несдантартные/кастомные в том числе). Он не требует подтверждения сессий, ключей, хэндшейков и прочей шняги - соответственно упрощая реализацию и уменьшая ТОТАЛЬНО оверхед, добавляя лишь около 20 байтов к сырым пакетам. Ну и как сказал, открывается возможность над полной манипуляцией raw пакетами - удобно для перенаправления, манипуляции ТТЛ, спуф и применения iptables/conntrack на хосте-форвардере.
Кратко говоря - меньше запара и производительнее