Fórum Root.cz
Hlavní témata => Server => Téma založeno: Sheldonizátor 06. 10. 2015, 21:39:45
-
Neví někdo, jestli je možnjé udělat, aby k aplikaci běžící na portu 80 někde v interní firemní síti bylo možno přistupovat i z netu, ale aby to jelo na portu 443, tedy SSL?
Dejme tomu, že aplikace je implementovaná jako normální HTTP a je to ručně zbastlený server poslouchající na portu 80 a aplikace je grafická, zkuchtěná v Delphi, a běží permanentně na windowsáckém serveru. Je možné nějak přesměrovat síť aby se udělal nějaký tunel že někdo z internetu by se připojoval přes port 443 na server kterej by to přeposílal do firemní sítě a zpátky kde by to už šlo nešifrovaně přes port 80?
Jde o to aby data po netu šla šifrovaná a aby se ale HTTPS nemuselo implementit přímo do aplikace.
-
Na tohle je přímo jako stvořený web server Nginx, který umí krásně fungovat jako reverzní proxy. V konfiguraci se mu zadá, kde má poslouchat, jaký certifikát a privátní klíč má používat a na který backend má dotazy předávat. Na vnější rozhraní tedy dáte Nginx na 80 a 443 a někde uvnitř sítě bude jen na 80 poslouchat váš server s daty.
-
Jaj no to je ale prasárna toto... není jednodušší to zpřístupnit normálně na portu 80 pouze přes VPN, nebo potřebuješ, aby na to přistupovali i normální lidi (nezaměstnanci)?
jinak mrkni sem https://www.stunnel.org/index.html
-
pripadne pokud by jiz bezel nekde v siti apache tak ten taky ma mod_proxy (jakkoliv nerikam, ze je to nejlepsi reseni tak muze byt nejvyhodnejsi)
-
Ten stunnel poběží klidně i na těch windowsech, nicméně si myslím, že jsou všechny řešení špatně. Evidentně je to nějaká neudržovaná kdovínaco aplikačka a to, že pojede přes ssl rozhodně neznamená, že bude nějak extra bezpečná. Záleží samozřejmě na tom, jak to má ošetřený přístupy, kdo na to poleze atd, ale možná bych se nad tím ještě 2x zamyslel, jestli není lepší to (nechat) přepsat nějak rozumněji.
-
Na tohle je přímo jako stvořený web server Nginx, který umí krásně fungovat jako reverzní proxy. V konfiguraci se mu zadá, kde má poslouchat, jaký certifikát a privátní klíč má používat a na který backend má dotazy předávat. Na vnější rozhraní tedy dáte Nginx na 80 a 443 a někde uvnitř sítě bude jen na 80 poslouchat váš server s daty.
Pokud dá na vnější rozhraní 443 i 80, tak se mu po prvním kliknutí na odkaz v tom webu https změní na http (pokud tedy nebudou relativní). Pokud to tazatel chce mít šifrované, tak proxy na vnějším rozhraní musí mít jen 443.
Ani takhle jednoduché to není, ta proxy by musela změnit všechny interní odkazy na https. Bohužel, i zavedené redakční systémy dělají interní odkazy jako absolutní, nikoliv relativní (u relativních by to fungovat mohlo, tam se o to postará prohlížeč). Nehledě na to, že některé RS zmate, když je jejich spojení na jednom schematu a klientu jde schema jiné.
Jednoduché řešení neexistuje, nejlepší bude (krom aktualizace daného webu a jeho zprovoznění na https), nějaký šifrovaný tunel.
-
možná bych se nad tím ještě 2x zamyslel, jestli není lepší to (nechat) přepsat nějak rozumněji.
heh. ses student nebo jen nejaky zamestnanec neziskovky/uradu?
-
možná bych se nad tím ještě 2x zamyslel, jestli není lepší to (nechat) přepsat nějak rozumněji.
heh. ses student nebo jen nejaky zamestnanec neziskovky/uradu?
Ani jedno, ani druhý. Nevím o té appce nic, jenom říkám, že je to na zvážení. Jestli je to 10 let nabalovanej bastl, kterej už nikdo 5 let neudržuje a nikdo vlastně ani neví, co a jak to dělá, tak je to samozřejmě problém, nicméně stejně bude dřív nebo později to něčím nahradit. Jestli je to něco malýho a jasně definovanýho, určitě se vyplatí to nechat za flašku rumu a pětikilo předělat nějakýho studenta.
Prostě jenom tvrdím, že to stojí za zvážení.
-
urcite bych zkusil NginX nebo mozna co https://mitmproxy.org/ (https://mitmproxy.org/) ?
-
Nebo treba Pound:
http://www.apsis.ch/pound/
-
https://brmlab.cz/user/jenda/ssl3
-
Proč se to tady vždycky zvrhne k tomu, že místo aby se řešil dotaz na naprosto konkrétní dobře ohraničenou záležitost - v tomhle případě dokonce naprosto jasný a dobře položený, tak se objeví rady jak to je určitě celé špatně a musí se to úplně zgruntu předělat.
Doporučení Nginx jde rozhodně dobrým směrem, toho bych se držel. Určitě na dané adrese zvenku povolit jen 443 a ne 80.
-
Zdar, ja mam to same udelano na Apache pres mod_proxy:
LoadModule proxy_module modules/mod_proxy.so
<VirtualHost *:443>
SslEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SSLCertificateFile /etc/SSLCerts/webSrv.cert.pem
SSLCertificateKeyFile /etc/SSLCerts/webSrv.key.pem
ServerName apache.local
ServerAlias *.apache.local
ProxyRequests off
ProxyPreserveHost on
ProxyPass / http://server.local:80/
ProxyPassReverse / http://server.local:80/
ErrorLog logs/apache.local-error_log
CustomLog logs/apache.local-access_log common
</VirtualHost>
-
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
Tohle tam máte schválně pro nějakého 20 let starého webového klienta? Uniká mi smysl s touto sadou šifer vůbec https zavádět.
-
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
Tohle tam máte schválně pro nějakého 20 let starého webového klienta? Uniká mi smysl s touto sadou šifer vůbec https zavádět.
Nastavoval jsem to podle http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html Potom zalezi na klientovi jake pouzije sifrovani. Server jich muze podporovat vice. V zasade v tom nevidim nic spatneho ze server podporuje i starsi klienty, z principu v mem pripade by mel klient vyzadovat co nejsilnejsi sifrovani.
-
Teke bych to řešil jednoduše přes nginx
a co se absollutnich odkazu tyka, tak lze na proxy na upravovat odpoved cili zamenit http:// za https:// mam pocit ze to ale pak chce balicek nginx-extras
jak na to: http://nginx.org/en/docs/http/ngx_http_sub_module.html
a kdyz uz tu nekdo vytahl bezpecnost, co vi vite treba tam autentizaci maji, ale proste to beha na http protoze to v interni siti staci, take duvodem muze byt slabsi hw jinak by stacilo prekonfigurovat server kde beha ta aplikace,
nadruhou stranu nazor na pouziti vpn je spravny mozna se zamyslet zda nejit touto cestou
-
Díky za odpovědi 8). Nepůjde nutně jen, i když nejspíše je. Co se předělávky týče, ano, někdo kdo četl mé minulé příspěvky ví že na něčem takovém teď dělám ;D.
Šifrování bohatě postačí, jde o to aby data nešla v plaintextu, a pokud by si někdo v budoucnu vymyslel že se některým klientům umožní vypnout/zapnout nějaký stroj, tak je dobré už nyní myslet na šifrování.
Navíc musím přiznat že webové věci dělat zatím moc neumím, proto mi přijde jako blbost si třeba implementovat vlastní webový server když už jsou odzkoušené a známe servery jako apache a nginx. A aby podporoval i šifrování, to by taky byla makačka to naprogramovat dobře...
-
Nepůjde nutně jen o web, i když nejspíše jo.
-
No jestli jde o ovládání něčeho, co dělá pár lidí z firmy, rozhodně je asi momentálně nejvíc bezproblémový jim dát VPNky. Ty si můžeš zašifrovat dle libosti, nemusíš řešit absolutní odkazy, když dobře nastavíš router, může to zůstat na stávající adrese a je to vyřešený řekl bych bez kompromisů. Z toho co píšeš a podle zkušeností který říkáš že máš/nemáš ti ani přepsání a implementace SSL nezaručí, že tam nebudeš mít nějakou zásadní chybu, přes kterou ti tam někdo vleze a něco ti provede.
-
Nastavoval jsem to podle http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html Potom zalezi na klientovi jake pouzije sifrovani. Server jich muze podporovat vice. V zasade v tom nevidim nic spatneho ze server podporuje i starsi klienty, z principu v mem pripade by mel klient vyzadovat co nejsilnejsi sifrovani.
Takto nastavený server může podlehnout změně šifry (útočník si může vybrat libovolnou nižší), vzhledem k tomu, že je tam i LOW, tak to jde lousknout už i brute force. Nehledě na to, že tam nikde nevidím zakázání protokolů SSL(v2, v3) a naopak tam vidím povolení šifry RC4, která už je také lousknutá.
Na tu dokumentaci bohužel evidentně nikdo roky nesáhl.
-
Nastavoval jsem to podle http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html Potom zalezi na klientovi jake pouzije sifrovani. Server jich muze podporovat vice. V zasade v tom nevidim nic spatneho ze server podporuje i starsi klienty, z principu v mem pripade by mel klient vyzadovat co nejsilnejsi sifrovani.
Takto nastavený server může podlehnout změně šifry (útočník si může vybrat libovolnou nižší), vzhledem k tomu, že je tam i LOW, tak to jde lousknout už i brute force. Nehledě na to, že tam nikde nevidím zakázání protokolů SSL(v2, v3) a naopak tam vidím povolení šifry RC4, která už je také lousknutá.
Na tu dokumentaci bohužel evidentně nikdo roky nesáhl.
Utocnik si ji sice vybrat muze, ale na nizsim sifrovani se serverem bude bavit pouze on. A "louskat" si muze tak mozna sve pakety :)
-
Utocnik si ji sice vybrat muze, ale na nizsim sifrovani se serverem bude bavit pouze on. A "louskat" si muze tak mozna sve pakety :)
Jsou útoky na snížení používané šifry (mezi klientem a serverem). Nelze se spoléhat na to, že si prohlížeč (který ani nemusí být aktuální a vybere si třeba RC4) vybere to nejlepší spojení, server by měl nabízet jen to, co je aktuálně považováno za bezpečné.
Ale je to vaše proxy, vaše data. Mě do toho nic není, chtěl jsem jen poradit.
-
Jsou útoky na snížení používané šifry (mezi klientem a serverem). Nelze se spoléhat na to, že si prohlížeč (který ani nemusí být aktuální a vybere si třeba RC4) vybere to nejlepší spojení, server by měl nabízet jen to, co je aktuálně považováno za bezpečné.
Ale je to vaše proxy, vaše data. Mě do toho nic není, chtěl jsem jen poradit.
Nic se nedeje. Diky za radu, zkusim se na to nastaveni mrknout.
-
server by měl nabízet jen to, co je aktuálně považováno za bezpečné.
Vskutku brilantní úvaha, takto se vypnulo SSLv3 a dost věcí se SSL přestalo fungovat. Ne všechno se dá aktualizovat, na některé produkty aktualizace nejsou a už nebudou nebo výrobce mezitím úplně zavřel krám. Mnoha lidem by RC4 nevadilo, stejně jedou přes VPN.
-
server by měl nabízet jen to, co je aktuálně považováno za bezpečné.
Vskutku brilantní úvaha, takto se vypnulo SSLv3 a dost věcí se SSL přestalo fungovat. Ne všechno se dá aktualizovat, na některé produkty aktualizace nejsou a už nebudou nebo výrobce mezitím úplně zavřel krám. Mnoha lidem by RC4 nevadilo, stejně jedou přes VPN.
Ano vždy se musí torchu přemýšlet a zvažovat pro a proti. Často člověk prostě musí lehce ustoupit protože zákazník miluje xp a explorer a žádná síla v tomhle vesmíru ho nepřiměje vyměnit ten přeci 10let funkční stroj když ještě bez problémů beží. S tím že on/zaměstanec to má jen na práci a nikam než sem a sem nechodí. Takže není důvod něco měnit když to tak pěkně funguje. Zázrak je když je donutíte na firefox nebo chrome, ale to se to pak začne krchat protože sou to potvory nenažraný takže spátky v lepším případě na ie8. Tenhle stav vyřeší jen blesk do rozvodů, staré kompy neměly kurvítka a umírat se jim nechce.
Jinak na to jestli máš dobře nastavený https existuje moře testovacích nástrojů a jsou i online řešení. A některá ti krom nabídky prodání jiného certifikátu řeknou co se jim nelíbý a jak to zlepšit.
-
Vskutku brilantní úvaha, takto se vypnulo SSLv3 a dost věcí se SSL přestalo fungovat. Ne všechno se dá aktualizovat, na některé produkty aktualizace nejsou a už nebudou nebo výrobce mezitím úplně zavřel krám. Mnoha lidem by RC4 nevadilo, stejně jedou přes VPN.
"se vypnulo" mělo nějaký vývoj a také je třeba připomenout, že SSLv3 je tu od roku 1996 a hned o tři roky později, tedy v 1999, přišlo TLS. SSLv3 "se vypnulo" v roce 2014, tedy 15 let po té, co existují alternativy.
Nehledě na to, že vždy existuje možnost, jak se tam připojit (Jenda má na své wikině návod na připojení mezi TLS a SSLv3, pokud někdo trvá na RC4, tak si může i za 10 let zkompilovat proxy, která se připojí na TLS a na druhé straně pojede klidně jako SSL v RC4). Možnosti vždy budou. Ale přece nemůže aktuální prohlížeč a server nabízet šifru, která je prolomená? K čemu by tam potom to celé šifrování bylo?
Btw u VPN je situace možná ještě horší. Kolem webserverů se alespoň občas dělá bouře a tam i poučení laici vědí, že sem tam nějaký protokol už není bezpečný. U VPN se tohle neděje, takže se i dnes najdou kousky s 1024b klíči, SHA1 podpisy na 56b šifře a na SSLv3 protokolu.
-
Jaj no to je ale prasárna toto... není jednodušší to zpřístupnit normálně na portu 80 pouze přes VPN, nebo potřebuješ, aby na to přistupovali i normální lidi (nezaměstnanci)?
Možná potřebuje, aby zaměstnanci s Windows 8 nezatěžovali ICT oddělení se zlobící VPN. CiscoVPN Client na Windows 8 nejede vůbec a v OpenVPN občas zamrzá spuštění adaptéru TAP. Na Windows 7 obě VPN běží jak víno.
-
Jiny widle nez sedmicky nemaji ve firemni sfere na desktopu absolutne co pohledavat.
-
Jaj no to je ale prasárna toto... není jednodušší to zpřístupnit normálně na portu 80 pouze přes VPN, nebo potřebuješ, aby na to přistupovali i normální lidi (nezaměstnanci)?
Možná potřebuje, aby zaměstnanci s Windows 8 nezatěžovali ICT oddělení se zlobící VPN. CiscoVPN Client na Windows 8 nejede vůbec a v OpenVPN občas zamrzá spuštění adaptéru TAP. Na Windows 7 obě VPN běží jak víno.
CiscoVPN na 8.x a 10 jede. I kdyz, musi se uz trochu tomu napomoci. Ale to neni ani tak chyba MS, jako rozhodnuti Cisco, ze tlaci AnyConnect.
-
Ano vždy se musí torchu přemýšlet a zvažovat pro a proti. Často člověk prostě musí lehce ustoupit protože zákazník miluje xp a explorer a žádná síla v tomhle vesmíru ho nepřiměje vyměnit ten přeci 10let funkční stroj když ještě bez problémů beží. S tím že on/zaměstanec to má jen na práci a nikam než sem a sem nechodí. Takže není důvod něco měnit když to tak pěkně funguje.
Nejvíce nase*ete zákazníka tím, že roky vypiplaný a odladěný produkt přes noc přestane fungovat. SSLv3 je přesně tento případ. Už kvůli tomu proběhly i změny smluv na přechod z SSL/TLS na jiné řešení.
-
Btw u VPN je situace možná ještě horší. Kolem webserverů se alespoň občas dělá bouře a tam i poučení laici vědí, že sem tam nějaký protokol už není bezpečný. U VPN se tohle neděje, takže se i dnes najdou kousky s 1024b klíči, SHA1 podpisy na 56b šifře a na SSLv3 protokolu.
Ano, ty defaulty v OpenVPN (1024b RSA + 1024b DH, alespoň tedy pokaždé jiné), Mikrotiku (1024b DSA SSH klíč, změněno teprve toto léto) a vůbec MS-CHAP (DES, používá se třeba v PPTP VPNkách nebo v eduroamu) mě fascinují.