Как обезопасить управление сервером?

Question

[Lamaster]

Недавно поймали владельца SilkRoad.

В связи с этим возникает вопрос как действительно управлять своим сервером?

У меня есть одна идейка: на сервере располагается скриптик, который читает определённый твиттер-аккаунт.

В этом аккаунте владелец располагает ссылки на pastebin.

На pastebin содержится код для управления сервером.

А на pastebin необходимо заходить с разных айпишников TOR'а.

Это могут быть просто строки кода, а может быть HEX-последовательность, подписанная публичным ключом.

Сервер проверяет подпись и декодирует исходник, после чего выполняет скрипт.

Для того, чтобы всё не легло из-за ошибок скрипта, всю его работу необходимо проверять на тестовом сервере.

В скрипте могут содержаться команды php или shell.

Я бы там располагал bash команды git pull с сервера bitbucket.

//

Может быть у меня всё слишком сложно? Какое бы решение использовали вы?

Answer 1

[m-haritonov]

Можно ещё устроиться в правительство или внедрить к ним своего агента.

Answer 2

[Lamaster]

Как вариант можно держать сервер в кладовке и подключаться напрямую.

Comments

[Sergey Cherepanov]

И желательно не подключать к нему интернет.

Answer 3

[kasthack]

SSH через I2P->I2P Outproxy->Tor->I2P
Бесплатно и просто. Правда, не очень быстро.

Comments

[Lamaster]

И вспоминать Dial-Up? Получится ооочень небыстро.
Кстати сейчас понял, что делать pull с Bitbucket не очень секурно, к нему же тоже может подобраться государство. Так что надо будет делать свои сервера.

[kasthack]

Подготовьте заранее shell-скрипт и работайте в пакетном режиме.
Предельная безопасность и удобство — обычно взаимоисключающие понятия.

Answer 4

[J_o_k_e_R]

Зачем это все? Какие проблемы вы видите в варианте Client->Private VPN->TOR->Private\PUblic VPN->Server?

Ну или ставите на сервер i2p-роутер, поднимаете на нем i2p-тунель на порт с ssh, а дальше из дома через i2p подключаетесь к этому тунелю. При работе по SSH проблемы со скоростью вряд ли будут.

Ах ну да. Откройте для себя ipv6 хотя бы через 6to4.

Comments

[Lamaster]

При взломе сервера (всё таки это возможный сценарий) и установлении прямого соединения с сервером возможно узнать некоторую информацию о моей системе или мне.

[J_o_k_e_R]

Уже видел эту Вашу точку зрения в комментах. Разъясните поподробнее, пожалуйста. Что именно можно узнать кроме легко подделываемой версии ssh клиента?

[Lamaster]

По сессии ssh возможно узнать удалённый IP клиента. А со знанием IP на конкретный момент времени на систему можно обрушить пак эксплоитов. Это ситуация почти невероятна, но она возможна.

[Lamaster]

Хотя IP будет светиться проксёвый. Признаю, тут моих знаний недостаточно.

[Lamaster]

Да, нашёл. Была уязвимость клиента Putty на этапе проверки ключей с возможностью выполнения произвольного кода.
www.exploit.in/modules.php?name=news&file=view&news_id=6319

[JDima]

Ну так развернуть виртуалку (метод подключения к сети — «бридж») и с нее администрировать. После окончания каждой сессии откатывать ее до снапшота «только что установил ОС и пару нужных программ». Никогда, ни при каких обстоятельствах не использовать эту виртуалку в иных целях.

[J_o_k_e_R]

lamaster, во-1, последний IP будет естественно IP последнего пира. Либо tor exit node, либо VPN сервиса. В случае public VPN типа ruvpn, на одном IP может сидеть несколько пользователей и он вообще никому ничего не даст. Ну или вообще будет 127.0.0.1, если делаем трюк с i2p-туннелем.

По поводу уязвимости в ПО. Я по умолчанию предполагал, что мы тут все большие мальчики и юзаем серьезный паццанский софт типа openssh. Если мы говорим про анонимность управления собственным сервером — забудьте про винду и putty.

JDima. Самый хардкор — livecd\dvd. Liberté Linux или gentoo live dvd, чтоб пересобрать openssh, замаскировав его под putty :-D Ключи\явки\пароли подтягиваем с криптованного раздела на хосте по sftp или просто с флешки.

[JDima]

J_o_k_e_R
Еще, кстати, надо внешними средствами запретить этой ОС общаться по сети с чего угодно кроме TOR. RCE может быть в чем угодно. Одного отправленного в обход TOR пакета на конкретный адрес достаточно для деанонимизации.

[J_o_k_e_R]

JDima
А может тогда подключение к сети не bridge, а наоборот NAT? И на хосте зарубаем доступ виртуалке ко всему кроме тора?

[JDima]

J_o_k_e_R
Это.
Немного фингерпринтинга хоста — то есть то, чего мы и хотим избежать. Может, статья специфична для VMWare, а может, аналогичные проблемы есть и других гипервизорах. Бридж все-таки должен гарантировать, что хост не станет вмешиваться в содержимое пакетов.

Зарубить доступ можно на следующем по цепочке роутере. А может, и на хосте. Политики IPTABLES к примеру будут работать для виртуалки с бриджевым соединением? Я честно не знаю. Но наверняка варианты есть.

Ну и конечно у виртуалки не должно быть глобально маршрутизируемого адреса.

[merlin-vrn]

Да, iptables можно фильтровать пакеты bridge. Будет оно или нет фильтроваться — определяется sysctl net.bridge.bridge-nf-call-iptables и ...-ip6tables

[J_o_k_e_R]

merlin-vrn, может тогда лучше ebtables (извините за выражение).

[merlin-vrn]

не, разница есть. iptables — это обычный iptables. а ebtables ничего не знает про ip-адреса и так далее. Т.е., например, с iptables и echo 1 > /proc/net/bridge/brighe-nf-call-iptables я получу возможность сопоставлять mac и ip отправителя, фразы вроде iptables --physdev-in tap0 --physdev-out eth0 -s 1.2.3.4 -m mac! --mac-source 00:11:22:33:44:55 -j DROP — с ebtables вы этого не сделаете

Answer 5

[Ilya Evseev]

У меня есть одна идейка: на сервере располагается скриптик, который читает определённый твиттер-аккаунт.
В этом аккаунте владелец располагает ссылки на pastebin.
На pastebin содержится код для управления сервером.
А на pastebin необходимо заходить с разных айпишников TOR'а.

Такое накручивание создает для правоохранительных органов всего три дополнительных шага:
— заставить хостера отследить исходящие запросы с сервера,
— получить всю информацию по аккаунту и посещениям у Твиттера,
— получить всю информацию по посещениям у Пастебина.

С их ресурсами и полномочиями — непринципиальная заминка.

Вам уже посоветовали использовать TOR и i2p.

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

Это застрахует Вас на 99%. А на оставшемся проценте Вас поймают.
Увы, но таковы правила игры в кошки-мышки.

Answer 6

[KEKSOV]

Было дело, приходилось управлять сервером через… e-mail :) все остальные каналы были закрыты безопасниками. На сервере стояла самописная клиентская программа, которая опрашивала внешний smtpd.

smtpd нужно расположить на внешнем vps сервере и забирать почту с него через цепочку OpenVPN тунелей (цепочка должна начинаться на управляемом сервере и терминироваться на smtpd vps), который прыгает по нескольким хопам, расположенным, желательно, в разных частях света, в странах типа Китая, Ирана и Пакистана. Почта, ессно, должна шифроваться и попадать на наш smtpd сервер через цепочку email форвардов, так же расположенных в экзотических странах. Цепочки email форвардов можно выстраивать самым запутанным образом с петлями и тупиками — чтобы было множество ложных путей.

Answer 7

[Lamaster]

Кстати, если twitter-аккаунт заблокируют, имя следующего акка должно равняться sha256(<old_account> + <private_password>)