Комментарии 47
Хорошая статья, спасибо. Но мне моя параноя не позволяет довериться почте. Подобный бот был для жаббера, вот это мне кажеться более безопасным решением.
Что-бы не запускались интерактивные приложения, можно указать TERM="".
Что-бы не запускались интерактивные приложения, можно указать TERM="".
Да про бот для жаббера слышал, но народ отзывался что его нужно допиливать.
Да и руки давно чесались опробовать питон в действии.
Спасибо за подсказку с TERM, попробую.
Да и руки давно чесались опробовать питон в действии.
Спасибо за подсказку с TERM, попробую.
А может ограничить время работы треда с выполнением процесса? А то «tail -f» и всё…
code.google.com/p/emailshell/source/browse/trunk/emailshell.py
я где то год назад новоял что то подобное за одним исключением.
gpg использовал… нужен один и тот же ключ на хозяине и на управляемом компе.
Посылаешь сообщение зашифрованное…
На компе управляемом расшифровывается, дальше вывод комманд зашифровывается и отправляется обратно.
я где то год назад новоял что то подобное за одним исключением.
gpg использовал… нужен один и тот же ключ на хозяине и на управляемом компе.
Посылаешь сообщение зашифрованное…
На компе управляемом расшифровывается, дальше вывод комманд зашифровывается и отправляется обратно.
НЛО прилетело и опубликовало эту надпись здесь
Ну, безопасность у этого «решения», боюсь, на уровне telnet в современном интернете. Хоть бы подписывали сообщения…
SSL/TLS для почты достаточно, чтобы не светить почту в открытую. Но это уже надо почтовый сервис настраивать.
Многие e-mail хостинги имеют поддержку SSL. В моём боте реализована поддержка использования как SSL соединения так и оычного
опечаточка вышла, имел в виду «обычного»
Это абсолютно ничего не дает: между SMTP-серверами почта будет почти наверняка ходить открыто.
Да ладно, в чем же тогда преимущество использования SSL? Как раз весь трафик будет передан внутри шифрованного соединения, полная аналогия с SSH-туннелированием.
в том что между клиентом и сервером будет шифрованное соединение. между сервера обычно нешифрованное и ходит.
<img src="facepalm.jpg"/>…
SSH-туннель — такая замечательная штука, где влияние внешних угроз очень здорово ограничено. В частности, вы абсолютно не зависите от той среды, через которую передается SSH-трафик. Вы не обязаны доверять серверам провайдера клиента, серверам провайдера хостинга сервера, любым промежуточным узлам. Есть понятие сессионного ключа, есть понятие ключей на endpoint'ах — а за счет интерактивности установки соединения можно делать многие штуковины, которые в однопроходном обмене в принципе невозможны.
При использовании SSL для соединения с SMTP-сервером у вас образуются следующие дырки, как минимум:
Любой в этой цепочке может либо стащить пароль, либо подменить трафик и отправить любую команду от вашего имени. При использовании SSH ничего подобного нет.
SSH-туннель — такая замечательная штука, где влияние внешних угроз очень здорово ограничено. В частности, вы абсолютно не зависите от той среды, через которую передается SSH-трафик. Вы не обязаны доверять серверам провайдера клиента, серверам провайдера хостинга сервера, любым промежуточным узлам. Есть понятие сессионного ключа, есть понятие ключей на endpoint'ах — а за счет интерактивности установки соединения можно делать многие штуковины, которые в однопроходном обмене в принципе невозможны.
При использовании SSL для соединения с SMTP-сервером у вас образуются следующие дырки, как минимум:
- вам приходится доверять SMTP-серверу провайдера (что он не подменит команду или просто не стырит драгоценные логин-пароль), т.к. он имеет на своей стороне конец SSL-сессии и весь трафик в нешифрованном виде
- вам приходится доверять всем SMTP-серверам по ходу движения почты — т.е. неширофованному, как правило, соединению, между SMTP-серверами в цепочке между отправителем и получателем.
- т.к. трафик скорее всего нешифрованный — вам приходится доверять среде, т.е. всем администраторам всех провайдеров и бэкбонов, через которые проходит сообщение
- вам приходится доверять SMTP-серверу на стороне провайдера у сервера в ДЦ
Любой в этой цепочке может либо стащить пароль, либо подменить трафик и отправить любую команду от вашего имени. При использовании SSH ничего подобного нет.
Если вы про подписывание через S/MIME — то, субъективно, это более сложный путь, чем подпись через GPG.
Если вы про SSL/TLS соединение при передаче письма от отправителя к SMTP-серверу и/или при забирании письма с IMAP/POP3-сервера — то, боюсь, это абсолютно ничем не поможет: между SMTP-серверами в подавляющем большинстве случаев почта ходит в открытую и вы влиять на это толком никак не можете.
Если вы про SSL/TLS соединение при передаче письма от отправителя к SMTP-серверу и/или при забирании письма с IMAP/POP3-сервера — то, боюсь, это абсолютно ничем не поможет: между SMTP-серверами в подавляющем большинстве случаев почта ходит в открытую и вы влиять на это толком никак не можете.
ну можно архивировать командный файл с помощью 7-zip с заранее определенным паролем.
этим можно будет избежать столь откровенной демонстрации данных которые должны быть скрыты.
да и результат можно отдавать в зашифрованном архиве.
этим можно будет избежать столь откровенной демонстрации данных которые должны быть скрыты.
да и результат можно отдавать в зашифрованном архиве.
в случае шифрования, придется использовать сторонний клиент для дешифровки. С мобильника уже не проверишь ничего.
с мобильника всегда можно постучаться на ближайший доступный девайс.
хотя это тоже извращение.
но все-равно отсылать в явном виде логин/пароль мне кажется неправильным.
кстати на тему отправки команд: у меня когда-то возникала подобная мысль.
но в качестве инструмента думалось использовать dropbox.
мониторить определенную папку на предмет появления новых файлов и отдавать результаты в другую — выглядит столь-же просто как и работа с почтой и даже в чем-то проще. ну и субъективно безопаснее :)
хотя это тоже извращение.
но все-равно отсылать в явном виде логин/пароль мне кажется неправильным.
кстати на тему отправки команд: у меня когда-то возникала подобная мысль.
но в качестве инструмента думалось использовать dropbox.
мониторить определенную папку на предмет появления новых файлов и отдавать результаты в другую — выглядит столь-же просто как и работа с почтой и даже в чем-то проще. ну и субъективно безопаснее :)
Можно использовать симметричное шифрование. В голове шифровать команду, а потом расшифровывать результат :)
НЛО прилетело и опубликовало эту надпись здесь
Классическая уязвимость man-in-the-middle. Злоумышленник ловит сообщение с кодом на лету посередине и вместо ваших легитимных команд вставляет свои. Код остается валидным, сервер их охотно выполняет.
НЛО прилетело и опубликовало эту надпись здесь
Пардон, не понял. «Сервер», где есть «постоянный код», как-то телепатически должен влезть в «голову» и произвести проверку?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Это все хорошо, но мы уже обсудили что команды могут требовать время для выполнения (например я захочу найти на терабайтном хранилище файлик с определенным текстом).
Так можно же посылать Control коды в терминал специально обрабатываемой командой — вроде #>cc [ASCII code number]
Дальше уже человек пусть сам думает — зависла программа или ждет ввода или еще чего. Чего не так — Ctrl-C.
Так можно даже в nano редактировать:
Дальше уже человек пусть сам думает — зависла программа или ждет ввода или еще чего. Чего не так — Ctrl-C.
Так можно даже в nano редактировать:
nano somefile
#>cc ^A
#>cc ^BS ^BS ^BS
мир
#>cc ^X ^C
А DNS tunneling не рассматривали? По-моему, он идеально решил бы вашу задачу.
а скриншот долговыполняемого приложения можно послать?
Безопасность управления можно было бы усилить одноразовыми паролями.
Например, вычисляется hash=HASH(salt, command, password) и на сервер передается salt:command:hash. Демон запоминает salt и не дает его повторно использовать. Для генерации строки с мобильного можно использовать свой доверенный https сервер.
Это не так удобно, но позволяет, во-первых, не дать полное управление системой при перехвате единственного письма, во-вторых, защищает от атак replay и man-in-the-middle.
Например, вычисляется hash=HASH(salt, command, password) и на сервер передается salt:command:hash. Демон запоминает salt и не дает его повторно использовать. Для генерации строки с мобильного можно использовать свой доверенный https сервер.
Это не так удобно, но позволяет, во-первых, не дать полное управление системой при перехвате единственного письма, во-вторых, защищает от атак replay и man-in-the-middle.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Демон для удаленного управления компьтером через e-mail