Comments 47
Хорошая статья, спасибо. Но мне моя параноя не позволяет довериться почте. Подобный бот был для жаббера, вот это мне кажеться более безопасным решением.
Что-бы не запускались интерактивные приложения, можно указать TERM="".
Что-бы не запускались интерактивные приложения, можно указать TERM="".
Да про бот для жаббера слышал, но народ отзывался что его нужно допиливать.
Да и руки давно чесались опробовать питон в действии.
Спасибо за подсказку с TERM, попробую.
Да и руки давно чесались опробовать питон в действии.
Спасибо за подсказку с TERM, попробую.
А может ограничить время работы треда с выполнением процесса? А то «tail -f» и всё…
code.google.com/p/emailshell/source/browse/trunk/emailshell.py
я где то год назад новоял что то подобное за одним исключением.
gpg использовал… нужен один и тот же ключ на хозяине и на управляемом компе.
Посылаешь сообщение зашифрованное…
На компе управляемом расшифровывается, дальше вывод комманд зашифровывается и отправляется обратно.
я где то год назад новоял что то подобное за одним исключением.
gpg использовал… нужен один и тот же ключ на хозяине и на управляемом компе.
Посылаешь сообщение зашифрованное…
На компе управляемом расшифровывается, дальше вывод комманд зашифровывается и отправляется обратно.
UFO just landed and posted this here
Ну, безопасность у этого «решения», боюсь, на уровне 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.
мониторить определенную папку на предмет появления новых файлов и отдавать результаты в другую — выглядит столь-же просто как и работа с почтой и даже в чем-то проще. ну и субъективно безопаснее :)
Можно использовать симметричное шифрование. В голове шифровать команду, а потом расшифровывать результат :)
UFO just landed and posted this here
Классическая уязвимость man-in-the-middle. Злоумышленник ловит сообщение с кодом на лету посередине и вместо ваших легитимных команд вставляет свои. Код остается валидным, сервер их охотно выполняет.
UFO just landed and posted this here
Пардон, не понял. «Сервер», где есть «постоянный код», как-то телепатически должен влезть в «голову» и произвести проверку?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Это все хорошо, но мы уже обсудили что команды могут требовать время для выполнения (например я захочу найти на терабайтном хранилище файлик с определенным текстом).
Так можно же посылать 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.
Sign up to leave a comment.
Демон для удаленного управления компьтером через e-mail