The OpenNET Project / Index page

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

Мультиплексирование 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, 01:25, 30/07/2012 [^] [ответить] [смотреть все]
  • +1 +/
    Насчёт CONNECT не знаю, а с обрезанным проводом или выключенным компом, точно заработает.
     
  • 2.6, Аноним, 13:34, 31/07/2012 [^] [ответить] [смотреть все]
  • +/
    Тогда и https не заработает, внезапно ... весь текст скрыт [показать]
     
  • 1.3, lnv, 19:09, 30/07/2012 [ответить] [смотреть все]  
  • +1 +/
    Connect не запрещен обычно для https/443, не?
     
     
  • 2.4, pavlinux, 19:42, 30/07/2012 [^] [ответить] [смотреть все]  
  • +/
    Как я понял, он хочет домой протянуть канал, через какого нить прорва.
    К примеру на MTC/Стрим банят всё.  
     
     
  • 3.5, lnv, 00:12, 31/07/2012 [^] [ответить] [смотреть все]  
  • +/
    Ну если только так.
     
  • 3.7, Аноним, 13:35, 31/07/2012 [^] [ответить] [смотреть все]  
  • +/
    Что, даже DNS А то есть iodine и тому подобное еще Капча согласна 77770... весь текст скрыт [показать]
     
     
  • 4.8, pavlinux, 16:33, 31/07/2012 [^] [ответить] [смотреть все]  
  • +/
    А с каких пор клиенты обрабатывают ДНС-запросы?
     
     
  • 5.10, filosofem, 21:53, 31/07/2012 [^] [ответить] [смотреть все]  
  • +/
    Он про ДНС-туннелирование, когда трафик пакуется в риквесты и TXT записи.
     
     
  • 6.11, pavlinux, 01:17, 01/08/2012 [^] [ответить] [смотреть все]  
  • +/
    Для поднятия днс-тунелля запрос все равно клиент должен отправить.  
     
     
  • 7.14, Аноним, 23:40, 03/08/2012 [^] [ответить] [смотреть все]  
  • +/
    И что Половина провов услужливо резольвит адреса Клиент - отправляет Днс з... весь текст скрыт [показать]
     
     
  • 8.15, Nas_tradamus, 11:53, 04/08/2012 [^] [ответить] [смотреть все]  
  • +/
    > И что? Половина провов услужливо резольвит адреса :). Клиент - отправляет. Днс
    > запросы. И получает. Ответы. Улавливаешь к чему это ведет? Да, это
    > тоже может быть транспортом, хоть и извращенским :)

    У меня за жизнь было где-то 5 провов и ни один не резолвил адреса. Лет 10 назад читал статью в хакере о том, как завернуть трафик в dns-запросы.

     
  • 8.16, pavlinux, 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, 13:32, 03/08/2012 [ответить] [смотреть все]  
  • +/
    На хабре на днях появлялась интересная статья на тему всех возможностей SSH. В том числе, там и это было.
     
  • 1.18, Elhana, 02:21, 14/08/2012 [ответить] [смотреть все]  
  • +/
    Поможет чуть замаскироваться не более... Все равно если кто-то постоянно что-то шлет не один хост - явный тунель - достаточно попробовать ssh соединение на порт кинуть, чтобы проверить.

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

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

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


     

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



      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor