@oChuDAo14 сен 2011 в 10:04

Демон для удаленного управления компьтером через e-mail

5 мин

Python *

Из песочницы

+46

Комментарии 47

@gescheit 14 сен 2011 в 10:35

Хорошая статья, спасибо. Но мне моя параноя не позволяет довериться почте. Подобный бот был для жаббера, вот это мне кажеться более безопасным решением.
Что-бы не запускались интерактивные приложения, можно указать TERM="".

@oChuDAo 14 сен 2011 в 10:44

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

Спасибо за подсказку с TERM, попробую.

@gescheit 14 сен 2011 в 11:11

А может ограничить время работы треда с выполнением процесса? А то «tail -f» и всё…

@oChuDAo 14 сен 2011 в 11:16

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

@gescheit 14 сен 2011 в 11:23

Тогда с другой стороны подойти: команда которая убьет предыдущую команду :)

@oChuDAo 14 сен 2011 в 11:36

Ага, наверное стоит завести пару служебных команд для бота, одну для отображения списка выполняемых заданий с pid-ами или неким внутренним id, а другую для принудительного завершения по id, чтобы ненароком не пристрелить соседа по пиду :)

@bazilxp 15 сен 2011 в 03:10

code.google.com/p/emailshell/source/browse/trunk/emailshell.py

я где то год назад новоял что то подобное за одним исключением.

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

Посылаешь сообщение зашифрованное…
На компе управляемом расшифровывается, дальше вывод комманд зашифровывается и отправляется обратно.

НЛО прилетело и опубликовало эту надпись здесь

@GreyCat 14 сен 2011 в 12:31

Ну, безопасность у этого «решения», боюсь, на уровне telnet в современном интернете. Хоть бы подписывали сообщения…

@drakmail 14 сен 2011 в 12:35

самым простым решением было бы создать прямой SSH-тоннель и забыть про все трудности, но, во-первых, этому мешает строгая политика безопасности

А дальше идет речь о боте, который отправляет письма открытым текстом по email… да, это конечно намного безопаснее, чем использовать SSH-туннель.

@AbnormalHead 14 сен 2011 в 12:59

SSL/TLS для почты достаточно, чтобы не светить почту в открытую. Но это уже надо почтовый сервис настраивать.

@oChuDAo 14 сен 2011 в 13:21

Многие e-mail хостинги имеют поддержку SSL. В моём боте реализована поддержка использования как SSL соединения так и оычного

@oChuDAo 14 сен 2011 в 13:24

опечаточка вышла, имел в виду «обычного»

@GreyCat 14 сен 2011 в 13:46

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

@oChuDAo 14 сен 2011 в 14:02

Да ладно, в чем же тогда преимущество использования SSL? Как раз весь трафик будет передан внутри шифрованного соединения, полная аналогия с SSH-туннелированием.

@gescheit 14 сен 2011 в 14:05

в том что между клиентом и сервером будет шифрованное соединение. между сервера обычно нешифрованное и ходит.

@GreyCat 14 сен 2011 в 14:31

<img src="facepalm.jpg"/>…

SSH-туннель — такая замечательная штука, где влияние внешних угроз очень здорово ограничено. В частности, вы абсолютно не зависите от той среды, через которую передается SSH-трафик. Вы не обязаны доверять серверам провайдера клиента, серверам провайдера хостинга сервера, любым промежуточным узлам. Есть понятие сессионного ключа, есть понятие ключей на endpoint'ах — а за счет интерактивности установки соединения можно делать многие штуковины, которые в однопроходном обмене в принципе невозможны.

При использовании SSL для соединения с SMTP-сервером у вас образуются следующие дырки, как минимум:

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

Любой в этой цепочке может либо стащить пароль, либо подменить трафик и отправить любую команду от вашего имени. При использовании SSH ничего подобного нет.

@bazilxp 15 сен 2011 в 07:34

Можно посылать сообщения зашифрованные PGP и тогда вопрос подмены частично решается… Только ключи должны быть приватные 100%, публичную часть (ключа хозяина не должен никто знать). Иначе можно будет подменять вывод сервера…

@GreyCat 14 сен 2011 в 13:43

Если вы про подписывание через S/MIME — то, субъективно, это более сложный путь, чем подпись через GPG.

Если вы про SSL/TLS соединение при передаче письма от отправителя к SMTP-серверу и/или при забирании письма с IMAP/POP3-сервера — то, боюсь, это абсолютно ничем не поможет: между SMTP-серверами в подавляющем большинстве случаев почта ходит в открытую и вы влиять на это толком никак не можете.

@unhappy 14 сен 2011 в 13:13

ну можно архивировать командный файл с помощью 7-zip с заранее определенным паролем.
этим можно будет избежать столь откровенной демонстрации данных которые должны быть скрыты.
да и результат можно отдавать в зашифрованном архиве.

@oChuDAo 14 сен 2011 в 13:15

в случае шифрования, придется использовать сторонний клиент для дешифровки. С мобильника уже не проверишь ничего.

@unhappy 14 сен 2011 в 13:21

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

кстати на тему отправки команд: у меня когда-то возникала подобная мысль.
но в качестве инструмента думалось использовать dropbox.
мониторить определенную папку на предмет появления новых файлов и отдавать результаты в другую — выглядит столь-же просто как и работа с почтой и даже в чем-то проще. ну и субъективно безопаснее :)

@gescheit 14 сен 2011 в 13:18

Можно использовать симметричное шифрование. В голове шифровать команду, а потом расшифровывать результат :)

@GreyCat 14 сен 2011 в 14:26

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

НЛО прилетело и опубликовало эту надпись здесь

@GreyCat 14 сен 2011 в 13:57

Классическая уязвимость man-in-the-middle. Злоумышленник ловит сообщение с кодом на лету посередине и вместо ваших легитимных команд вставляет свои. Код остается валидным, сервер их охотно выполняет.

НЛО прилетело и опубликовало эту надпись здесь

@GreyCat 14 сен 2011 в 14:23

Пардон, не понял. «Сервер», где есть «постоянный код», как-то телепатически должен влезть в «голову» и произвести проверку?

НЛО прилетело и опубликовало эту надпись здесь

@GreyCat 14 сен 2011 в 14:34

Еще раз: это классический man-in-the-middle; ваше «тело письма» с логином и двумя паролями (статическим и из СМС) ловят по дороге, убирают оттуда невинные команды типа "/sbin/ip a" и вставляют другие команды, затем отправляют дальше. Сервер получает корректные логин и два пароля и выполняет.

НЛО прилетело и опубликовало эту надпись здесь

@GreyCat 14 сен 2011 в 14:44

тогда зачем вообще нужны пароли и СМСки?

НЛО прилетело и опубликовало эту надпись здесь

@oChuDAo 14 сен 2011 в 14:41

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

НЛО прилетело и опубликовало эту надпись здесь

@oChuDAo 14 сен 2011 в 14:47

Прошу прощения, сразу не понял вашу идею. Звучит не плохо, обязательно реализую.

@jaspeen 14 сен 2011 в 18:07

Так можно же посылать Control коды в терминал специально обрабатываемой командой — вроде #>cc [ASCII code number]
Дальше уже человек пусть сам думает — зависла программа или ждет ввода или еще чего. Чего не так — Ctrl-C.

Так можно даже в nano редактировать:

nano somefile

#>cc ^A

#>cc ^BS ^BS ^BS

мир

#>cc ^X ^C

@aml 14 сен 2011 в 17:11

А DNS tunneling не рассматривали? По-моему, он идеально решил бы вашу задачу.

@oChuDAo 14 сен 2011 в 20:46

Вариант конечно интересный, но UDP не самый лучший протокол. К томуже прийдется использовать нестандартный клиент для работы поверх DNS.

@aml 15 сен 2011 в 06:33

Спокойно делается IP поверх DNS. А по этому IP запускайте обычный ssh.

@bazilxp 15 сен 2011 в 07:35

был проект заворачивать PPPD через jabber траффик.

@gloomy2 14 сен 2011 в 19:25

а скриншот долговыполняемого приложения можно послать?

@qmax 15 сен 2011 в 06:44

ещё можно через астериск:
habrahabr.ru/blogs/sysadm/127997/

@Captain_Flint 15 сен 2011 в 08:12

Так, к слову: некогда в debian был такой пакет как grunt — «Secure remote execution via UUCP or e-mail using GPG». Документации, правда, не было, а на за запрос автор мне ответил просто — «читай исходники», что и пришлось делать :)

@ashcan 15 сен 2011 в 10:30

Безопасность управления можно было бы усилить одноразовыми паролями.
Например, вычисляется hash=HASH(salt, command, password) и на сервер передается salt:command:hash. Демон запоминает salt и не дает его повторно использовать. Для генерации строки с мобильного можно использовать свой доверенный https сервер.
Это не так удобно, но позволяет, во-первых, не дать полное управление системой при перехвате единственного письма, во-вторых, защищает от атак replay и man-in-the-middle.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий