The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Мультиплексирование ssl/ssh соединений через один 443 порт
В рамках проекта sslh (http://www.rutschle.net/tech/sslh.shtml) развивается
мультиплексор ssl/ssh соединений, способный принимать соединения на одном порту
и перебрасывать их в зависимости от типа протокола. Поддерживается широкий
спектр протоколов, среди которых  HTTP, HTTPS, SSH, OpenVPN, tinc и XMPP.
Наиболее востребованным применением sslh является обход межсетевых экранов,
допускающих только ограниченное число открытых портов.

Например, запустив sslh за пределами межсетевого экрана на 443 порту, можно
организовать работу SSH и любых других протоколов: соединение с внешней системы
будет производиться на 443 порт, но пробрасываться на локальный 22 порт, при
этом штатные HTTPS-запросы будут перебрасываться на localhost:443.

Для обеспечения работы такой схемы sslh следует запустить с опциями:

   sslh --user sslh --listen 192.168.10.15:443 --ssh 127.0.0.1:22 --ssl 127.0.0.1:443

где, "--user sslh" определяет пользователя, под которым следует запустить sslh;
"--listen 192.168.10.15:443" - IP и порт для приёма внешних соединений;
"--ssh 127.0.0.1:22" - IP и порт для проброса SSH
"--ssl 127.0.0.1:443" - IP и порт для проброса HTTPS
 
30.07.2012 , Источник: http://linuxaria.com/pills/sslh-a-s...
Ключи: ssl, ssh, proxy, redirect, firewall / Лицензия: CC-BY
Раздел:    Корень / Администратору / Сетевая подсистема, маршрутизация / Туннелинг, VPN, VLAN

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Alex (??), 00:03, 30/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Занимательно.
    Насколько я понял - прежде всего для всевозможных хотспотов, где есть только 80 и 443. Только вопрос - заработает ли, если например метод connect запрещен?
     
     
  • 2.2, pavlinux (ok), 01:25, 30/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Насчёт CONNECT не знаю, а с обрезанным проводом или выключенным компом, точно заработает.
     
  • 2.6, Аноним (-), 13:34, 31/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > если например метод connect запрещен?

    Тогда и https не заработает, внезапно.

     

  • 1.3, lnv (??), 19:09, 30/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Connect не запрещен обычно для https/443, не?
     
     
  • 2.4, pavlinux (ok), 19:42, 30/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Как я понял, он хочет домой протянуть канал, через какого нить прорва.
    К примеру на MTC/Стрим банят всё.  
     
     
  • 3.5, lnv (??), 00:12, 31/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну если только так.
     
  • 3.7, Аноним (-), 13:35, 31/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > К примеру на MTC/Стрим банят всё.

    Что, даже DNS? А то есть iodine и тому подобное еще :)
    Капча согласна: 77770

     
     
  • 4.8, pavlinux (ok), 16:33, 31/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А с каких пор клиенты обрабатывают ДНС-запросы?
     
     
  • 5.10, filosofem (ok), 21:53, 31/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Он про ДНС-туннелирование, когда трафик пакуется в риквесты и TXT записи.
     
     
  • 6.11, pavlinux (ok), 01:17, 01/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Для поднятия днс-тунелля запрос все равно клиент должен отправить.  
     
     
  • 7.14, Аноним (-), 23:40, 03/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    И что? Половина провов услужливо резольвит адреса :). Клиент - отправляет. Днс запросы. И получает. Ответы. Улавливаешь к чему это ведет? Да, это тоже может быть транспортом, хоть и извращенским :)
     
     
  • 8.15, Nas_tradamus (ok), 11:53, 04/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    У меня за жизнь было где-то 5 провов и ни один не резолвил адреса Лет 10 назад ... текст свёрнут, показать
     
  • 8.16, pavlinux (ok), 17:01, 06/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вы явно не в тему Я про то, кто инициирует соединение А для DNS-тунеля ваще о... текст свёрнут, показать
     

  • 1.9, Jokerjar (?), 18:33, 31/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм, я на сервере просто зеркалирую с помощью iptables SSH на 443 порт (можно просто настроить SSH на работу на этом порту). С работы коннекчусь на него нормально через цепочку прокси. Учитывая наличие SSH-туннеля, могу подключиться хоть чем и хоть куда. Profit!
     
  • 1.12, alp (?), 18:10, 02/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как логами быть? IP же будет локальный писаться.
     
     
  • 2.17, Иван Иванович Иванов (?), 02:21, 10/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    1) логи самого sslh
    2) логи iptables (--syn --state NEW)
     

  • 1.13, Nas_tradamus (ok), 13:32, 03/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На хабре на днях появлялась интересная статья на тему всех возможностей SSH. В том числе, там и это было.
     
  • 1.18, Elhana (ok), 02:21, 14/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Поможет чуть замаскироваться не более... Все равно если кто-то постоянно что-то шлет не один хост - явный тунель - достаточно попробовать ssh соединение на порт кинуть, чтобы проверить.

    Если уж совсем шифроватся - нужно сделать клиент открывающий два https соединения со специальным сервером - get и post - в один писать, другой читать и через эту байду тунелить...

    Мои параноики вообще поставили https proxy от bluecoat (?), по сути MITM и режут/читают все.

    На каждую хитрую жопу найдется свой болт на 18 и на каждый болт найдется своя жопа с лабиринтом.


     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру