Názory k článku SSLH: SSH, SSL, VPN a další služby na jednom portu
-
RS (neregistrovaný)
Presne na ten samy problem jsem bohuzel take narazil. Nicmene zda se ze uz to maji poresene:
On Linux (only?) you can use the --transparent option to request transparent proying. This means services behind sslh (Apache, sshd and so on) will see the external IP and ports as if the external world connected directly to them.
Ale zkusenosti s tim flagem nemam, budu rad kdyz mi nekdo napise zda je to uz oka
-
Nevim, jak v novych distribucich, ale treba Apache v Ubuntu 12.04 ma v configu nasledujici:
martin@eu:~$ cat /etc/apache2/sites-available/default-ssl
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
....
Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>a jiste to bude i jinde. A spousta php aplikaci taky. Zabezpeceni z localhostu se vetsinou moc neresi.
-
Ondřej CaletkaZlatý podporovatelJá bych si tedy VPN založenou na TCP-over-TCP nedovolil označit ani náhodou za něco co funguje „k naprosté spokojenosti“. Vypadá to, že to funguje, ale jen do chvíle, než na přenosové trase dojde k prvnímu výpadku nebo zpoždení.
Více v známém článku Why TCP Over TCP Is A Bad Idea.
-
Ilmarinen (neregistrovaný)
Zase tak pomalé to není. Dá se z toho stabilně vytáhnout přes 5Mbit/s download (podotýkám, že to připojení je z principu nesymetrické, podobně jako ADSL), ale v tomhle případě se snad nebavíme o A++ grade VPN připojení.
Popravdě, DNS tunel používám jen díky wifi síti dotované jihomoravským krajem, respektive provozované pod IDS JMK. To je přesně ten typ zkriplené konektivity, kde jediné, co funguje je port 80 a 443 a pak ještě DNS překlady a ping.
Pokud máš nestabilní připojení, kde je vysoká latence a navíc se sem tam nějaký packet ztratí, už se ten efekt TCP-in-TCP projeví.
Z tohoto pohledu je tedy lepší pro VPN používat protokoly, které neřeší retransmisi ztracených dat, ale nechat to řešit až v tunelovaných protokolech (hezkým příkladem je sada protokolů AH/ESP používaných pro IPSec, který má mimochodem fallback i na UDP), a nebo již zmiňovaná VPN over DNS nebo VPN over ICMP.
-
Ilmarinen (neregistrovaný)
Donutil jsi mě v práci rebootovat do linuxu a vyzkoušet to na naší konektivitě.
Použil jsem speedtest.cesnet.cz a naměřené rychlosti jsou 25Mbit/s download a 22Mbit/s upload.
Konektivita v práci je 250Mbit, noťas připojen přes 100Mbit rozhraní, konektivita k mému VPN serveru je 100/60Mbit
-
Ilmarinen (neregistrovaný)
Tím jsem myslel, že můžeš použít třeba OpenDNS nebo googlí DNS nebo cokoliv jiného. Ten iodine má výhodu v tom, že je schopen udělat autodetekci a vybrat si nejvhodnější protokol/DNS dotaz. V případě, že je otevřená komunikace do světa na portu udp/53, bude posílat přímá data, pokud by tam byla nějaká inspekce na sedmé vrstvě, bude posílat DNS dotazy.
-
Ilmarinen (neregistrovaný)
DNS VPN se nedá použít skrz HTTP proxy, ale to ani není potřeba. Jelikož můžeš udělat DNS překlad (to už by musela být skutečně dojebaná síť, která by nedovolila ani DNS překlady), o „proxy“ se ti postará DNS server, vůči kterému budeš dělat DNS překlady (klidně i ten, co ti síť vnutí přes DHCP).
Nastuduj si, jak funguje překlad DNS na IP, a pak si jen uvědom, že místo regulérních DNS dotazů posíláš data, co se jako DNS dotaz tváří.
-
_ Tonda (neregistrovaný)
Pokud se někde ve vnitřní síti vynucuje přístup přes proxy, pak není důvod aby tam fungovalo externí DNS, protože překlad stejně bude dělat ta proxy, a pokud něco není potřeba, tak to logicky každý rozumný admin/bezpečák zakáže, IMO nic výjimečného např. ve firemním prostředí
C:\Users\xxx>ping www.seznam.cz
Ping request could not find host www.seznam.cz. Please check the name and try again.C:\Users\xxx>nslookup www.seznam.cz
Server: xxx.cz
Address: 10.xxx*** xxx.cz can't find www.seznam.cz: Non-existent domain
-
Ondřej CaletkaZlatý podporovatel
Pokud je dostupný neomezený přístup na port 443, je asi nejjednodušší SSH na portu 443 a na něm spustit SSH tunel, ať už statický, nebo dynamický.
Pokud je na portu 443 nějaké DPI zařízení, které pustí jen TLS provoz, je nejlepší mít na web serveru podporu režimu proxy a příkazem HTTP CONNECT se zase spojit k nějakému SSH serveru. To by mohl být zajímavý námět na další článek :) -
_ Tonda (neregistrovaný)
SSH na port 443 skrz HTTP proxy používám, se zapnutým dynamickým port forwardingem (-D parametr) se to chová jako SOCKS proxy, kterou spousta aplikací umí přímo použít a ostatní lze většinou donutit prográmkem FreeCap či WideCap. Nebo lze přes FreeCap spustit http proxy jako třeba Proxy+ a tu pak použít v aplikaci, která umí jen HTTP proxy a nefunguje přes FreeCap.
Výhoda je, že lze nastavovat po aplikacích zda se bude komunikovat přímo či přes tunel, taká je daleko snazší to spustit, v podstatě stačí nakopírovat a spustit putty, což může i běžný uživatel. VPN potřebuje instalovat síťové rozhraní, což může jen admin.
Výhoda VPN je snazší přepínání celého provozu přímo/přes VPN a větší univerzálnost, přes SSH tunel asi nepojedou aplikace vyžadující UDP.
SSLH jsem chtěl zkusit pro multiplex OpenVPN a SSH, ale nakonec jsem se ktomu nedokopal, protože sem tu OpenVPN zas až tak nutně nepotřeboval.
Každopádně mi vrtá hlavou zda se při tunelování TCP spojení přes SSH rovněž může vyskytnout TCP over TCP problém, když defacto také tuneluji TCP spojení přes jiné TCP spojení.
-
Ondřej CaletkaZlatý podporovatel
Každopádně mi vrtá hlavou zda se při tunelování TCP spojení přes SSH rovněž může vyskytnout TCP over TCP problém, když defacto také tuneluji TCP spojení přes jiné TCP spojení.
Nikoli, SSH tunelování pomocí příkazů -L, -R a -D koncept TCP-in-TCP nepoužívá, místo toho jde o sérii tří nezávislých TCP spojení, kde první jde od klienta a končí na SSH klientovi/serveru (pro -L,-D resp. -R), druhé je vlastní SSH spojení na SSH server/klienta a odtamtud pokračuje třetí nezávislé TCP spojení z SSH serveru/klienta na tunelovaný server.
Jediný případ, který může být nebezpečný z hlediska TCP-in-TCP je spouštění PPP protokolu nad SSH, nebo tunelování pomocí tun zařízení (přepínač -w).
Jinak samozřejmě, SSH tunelování (pomocí příkazů -L, -R a -D) nepodporuje UDP, ale ono UDP-over-TCP by stejně moc dobře nefungovalo.
-
Tak určitě. :-) Já vím, že to samozřejmě nemůže za žádnou cenu fungovat, ale i přesto to osobně využívám přes deset let :-)
Na stejné IP mi běží primární UDP VPNka a pokud se na ni nedostanu, mám další instanci na TCP portu 443, kterou mohu použít v případech, že je UDP provoz blokovaný.
Rád bych potvrdil všechny teorie o tom, že TCP VPN nemůže fungoval, ale bohužel nemůžu sloužit, nikdy jsem nenarazil na problém :-( A to jako klienty používám Linux, OS X i iOS zařízení (iPhone a iPad)... -
JirkaS (neregistrovaný)
Ano, TCP-over-TCP určitě není dobrý nápad, ale vlastní zkušenost říká, že se to používat dá (zvlášť myslím ty případy, kdy člověku nic jiného nezbývá).
Teď používám OpenVPN po UDP, předtím jsem ale několik let používal OpenVPN po TCP a nenarazil jsem na problém (přičemž jsem dokonce míval OpenVPN server na ADSL lince).
A ještě předtím (páni, to už je víc jak deset let) jsem tuneloval ppp skrz ssh a také to fungovalo. A dokonce jsem tuto kombinaci zkoušel přes GPRS (mobil připojený přes IrDA) a taky to šlo. :-) -
ebik (neregistrovaný)
zkontroluj kterou adresu menis (aby to nebyla ta "listen") a ze neni po ceste zadny firewall, ktery spojeni zahazuje do cerne diry. Dale pak nevim, jak v tom bude fungovat to --transparent (zjisti si zda to neni zapnute), to uz je pak pokrocila routovaci sitarina
sam jsem to jeste nezkousel, ale tohle jsou prvni veci, co bych zkontroloval
-
Jenda (neregistrovaný)
> Neni lepsi si na rekneme 443 zridit VPNku a vsechen provoz smerovat skrz ni?
Není, protože si společnost vymyslela, že bude mít nedostatek čísel („IP adres“) a tím na sebe upletla bič. Těch, kdo tvrdí, že čísel by mělo být dost pro každého, je zatím jen pár procent a s ostatními komunikovat nemohou.
-
bobo (neregistrovaný)
Ahoj, sslh funguje na portu 443, forwarduje v poradku na https web i na ssh, ale openvpn ne. Zkousel jsem zvetsit timeout, ale nepomohlo, OpenVPN server bezi a v poradku se na nej da pripojit, ale kdyz ho presunu na localhost, tak ho sslh neforwarduje. Nevim jak to odtroubleshootovat sslh nema nikde logy. V logu openvpn nic neni, protoze se tam zadny traffic asi ani nedostane.
netstat -atupn | grep 1194 mi vyhodi 127.0.0.1:1194 openvpn, jako kdyby sslh nerozpoznal ten vpn traffic (pritom v configu mam --openvpn) gui okno openvpn hodi akorat hlasku, ze se nemuze pripojit, bez zadneho dalsiho erroru.
B. -
j (neregistrovaný)
Mno ... podle me se tim vyrabi velmi slusna bezpecnostni dira.
1) jak tu bylo zmineno, problem s IPcky
2) dalsi potencielne derava aplikace vystavena do netu
3) nejspis taky slusny postranni kanalJinak ad site ... ve firemnich sitich sem zastancem pristupu povolit jen to, co je nezbytne nutny (i na odchozim provozu). Ne ze by to pomohlo nejak zvlast, ale cihlicka k cihlicce.
Ve verejnych sitich sem prozmenu zastancem pristupu "delejte si co chcete". Nebot haxorovi stejne nezabranim aby z moji site sejmul neco v nasa ... a beznym userum omezenima jen hazu klacky pod nohy.
BTQ: Pocitac ktery se hacknout necha si nic jinyho nezaslouzi.
-
čavo (neregistrovaný)
Netuším čo robím zle:
Na mojom gentoo mám verziu: net-misc/sslh-1.15
Je spustený s parametrami: /usr/sbin/sslh --listen 192.168.145.2 44 --ssh 127.0.0.1 22 --http 127.0.0.1 443 --user nobody --pidfile /var/run/sslh.pid
počúva: netstat -nplt | grep ":44 "
tcp 0 0 192.168.145.2:44 0.0.0.0:* LISTEN 23795/sslhAle požiadavku od wget:
$ wget https://192.168.145.2:44/
--2014-07-07 20:26:55-- https://192.168.145.2:44/
Pripájam sa k 192.168.145.2:44... pripojené.
GnuTLS: An unexpected TLS packet was received.
Nepodarilo sa nadviazať SSL spojenie.posiela do ssh:
Jul 7 20:26:55 capor sslh[23795]: connection from arnold:59396 to arnold:mpm-flags forwarded from localhost:48423 to localhost:ssh
Jul 7 20:26:55 capor sshd[25647]: Bad protocol version identification '\026\003' from 127.0.0.1 port 48423Keďže som nenašiel žiadny konfigurák s predpisom, podľa čoho sa má rozhodovať, asi niečo také bude priamo zakódované priamo v zdrojákoch.
Kým sa cez ne začnem prehrabávať. Nerobím niekde priamo viditeľnú chybu?
-
A co využít SNI, máte s tím někdo praktický zkušenosti? Prohlížeče už to dávno podporují. Já jsem teda Windows admin a pokud bych řešil zmíněný problém, tak bych zvážil provozovat na jedné IP adrese HTTPS web(y) i bránu pro připojování k serveru: Remote Desktop Gateway jako standardní součást Windows Serveru. Balí RDP protokol do HTTPS. Tudíž s firewally není problém. Ale se SNI nemám praktické zkušenosti, co se týče podpory klientů. RDP ale díky TS Gateway funguje přes HTTPS bez problémů.
-
SNI běžně používám, podpora na straně klientů je výborná. Probléme mají jen uživatelé s kombinací Windows XP a IE. Před třemi lety to bylo 15 % klientů, dnes to bude mnohem méně. Zkusím zjistit aktuální čísla.
Pokud je možnost balit do HTTPS jiné protokoly, mělo by to fungovat. Praktickou zkušenost s tím ale nemám.
-
Filip JirsákStříbrný podporovatelPro tohle je spíš vhodné NPN (Next Protocol Negotiation). Některé web servery už to podporují, a pro klienta by to mělo být transparentní – tj. pokud klient umí jen HTTPS, nic se pro něj nemění, teprve pokud chce klient podporovat jiný protokol, musí použít NPN.
-
Snehuliak (neregistrovaný)
Co sa tyka spomenuteho problemu TCP over TCP - author cope Sam hovori ze odporuca a pouziva OpenSSH:
http://sites.inka.de/~bigred/devel/cipe.html -
diky za pekny clanek. uz delsi dobu tuneluju v linuxu na svuj VPS na pateri pomoci SSH (napr.: ssh -D 12345 user@server -p 443), apt-get a dalsi non-gui programky zenu pres tsocks (napr.: sudo tsocks apt-get upgrade). mam ale problem s flashem. na strankach jako youtube mi vsechno jede pres SSH tunel. na jinych strankach se mi obsah stranky nacte pres tunel, ale flash video se snazi pristupovat naprimo. treba aktualne ivysilani.cz mi chvili jelo pres tunel a po reloadu stranky uz se snazi jen na primo, coz nechapu. strycek gugl mi prozradil, ze flash neumi socks proxy. dle diskuze tady existuje freecap a widecap, ale to je win tool. jak v linuxu poslat i flash skrz ssh tunel ? popr. lze jako u freecap i v linuxu vytvorit HTTP proxy, ktera bude posilat do SSH tunelu ?
-
to jsem zkousel, bohuzel bezvysledne. proste obcas flash obchazi nastaveni prohlizece a natvrdo leze naprimo na net. nekdo zase psal, ze si flash udajne bere nastaveni ze systemu, tam ten tunel nemam nastaveny pro cely system. kdybych to chtel resit pro cely OS, tak si pustim VPN, ale mym cilem tohle reseni neni ... ale jak to vidim, tak mi nic jineho asi nezbyde...
-
Dr.Tič (neregistrovaný)
Prográmek vypadal nadějně. Avšak při instalaci na Ubuntu si doinstaloval i balík apache2, který po nakonfigurování i spustil.
Myslel jsem si, že má obsluhu portu 443 ve vlastní režii a že se spouští přes inetd (jak mi po instalaci nabídnul). Místo toho ale spustí trvale běžící procesy Apache.
Škoda. Tímto jsem s ním skončil.
Jinak článek dobrý. Na strojích, kde můžou trvale běžet mraky procesů, si program určitě svoje místo najde. -
ebik (neregistrovaný)
Aha, tak chyba nebude v ubuntu ale mezi klavesnici a zidli prispevatele na ktereho jsem reagoval. Vypis popisu balicku v debianu nasleduje (a predpokladam ze v bubuntu bude stejny).
$ apt-cache show sslh
...
Recommends: apache2 | httpd, openssh-server | ssh-server
Suggests: openbsd-inetd | inet-superserver
...Recommended zavislosti se (podle nastaveni) tusim instaluji, ale nejsou potreba a lze je odinstalovat (nebo zakazat jejich instalaci). Pokud tam nebyl zadny webserver (tedy nic co by provides httpd), tak to zkusilo splnit Recommends tim apachem.
ČLÁNKY DO MAILU
