none
Nastavení firewallu u standalone serveru v cloudu RRS feed

  • Dotaz

  • Řeším následující věc. Klasický standalone server v cloudu s Windows 2016 ve dvou scénářích.

    1. V prvním případě na serveru běží jedna apka + sql server. Na firewallu povolen jen RDP protokol na upraveném portu a sql server opět na upraveném portu (myšleno jiném než výchozím). Když otestuji otevřené porty přes online port skener, nenajde žádný otevřený port v množině 1000 standardních vybraných portů. To je OK, s použitím ještě dalších technik myslím, že je server v rámci možností zabezpečen dobře.

    2. Druhý případ - na serveru je nainstalovaná role AD, DNS, RDS a další nezbytnosti tak, aby bylo možné používat nainstalovanou aplikaci přes RemoteApp a licencovat per user. Když otestuji tento server na otevřené porty, je jich najednou mraky otevřených. Jedná se o tyto porty:

    53/tcp   open  domain
    80/tcp   open  http
    88/tcp   open  kerberos-sec
    135/tcp  open  msrpc
    139/tcp  open  netbios-ssn
    389/tcp  open  ldap
    443/tcp  open  https
    445/tcp  open  microsoft-ds
    464/tcp  open  kpasswd5
    593/tcp  open  http-rpc-epmap
    636/tcp  open  ldapssl
    3268/tcp open  globalcatLDAP
    3269/tcp open  globalcatLDAPssl
    Nmap done: 1 IP address (1 host up) scanned in 20.44 seconds

    Otázka je, zdali musí být tyto všechny porty otevřené, když se jedná o standalone server, ke kterému se přistupuje jen přes RDP nebo uživatelé jen přes RemoteApp.

    Děkuji za rady.

    středa 25. září 2019 19:04

Všechny reakce

  • Ahoj.

    1. Změna portu není zabezpečení. Je to naprosto zbytečné. Útočník proskenuje všech cca 65 tisíc portů a podle odpovědi pozná, co je za tím portem za službu, takže měnit port je zcela k ničemu a spíš to způsobuje komplikace pro běžné aplikace, ale žádný přínos z pohledu bezpečnosti. SQL ani RDP nikdy neotvírej do internetu. NIKDY. U SQL by něco takového nemělo být ani nikdy potřeba - SQL by měl běžet jen po lokální síti. U RDP opět jen lokální síť (VPN) nebo přes RDGW.

    2. Instalací rolí se otvírají porty na integrovaném FW. Nepočítá se s tím, že by doménový řadič byl vystavený na veřejné IP do internetu. Rozhodně to zakaž nebo ještě lépe server nech jen s lokální IP a forwarduj na něj jen potřebné porty nebo před server postav nějaký firewall (optimálně s IPS/IDS, pokud už potřebuješ do internetu vystrčit SQL a RDP).

    čtvrtek 26. září 2019 9:00
  • Co se týče změny portu, tak o tom nechci polemizovat, vycházím z předpokladu, že nikde neskenuje všech 65tis. portů, ale jde po standardních.

    Jinak jak jsem psal, je to klasické VPS, bez další infrastruktury, kterou mohu ovlivnit, server je vystrčen přímo do netu. Ale podle poskytovatele je tam síťová ochrana proti vnějším útokům DDoS. Neumím posoudit, ale třeba proskenování těch 1000 portů trvalo cca 20 sekund. Netuším, zdali by někdo vydržel skenovat všech 65 tis, což by představovalo cca 21 minut.

    Zkusím to postupně všechno blokovat a uvidím.

    čtvrtek 26. září 2019 9:14
  • Pokud poskytovatel neumožňuje aplikovat rozumné zabezpečení, pak by možná stálo za to uvažovat o změně poskytovatele :-) Protože takto vystrčit do internetu citlivé služby je krajně riskantní a úplně to volá po nějakém průšvihu.

    čtvrtek 26. září 2019 10:01
  • Trošku se dostáváme mimo původní dotaz. Samozřejmě kritické věci řeším přes Azure a Lan-to-Lan VPN do on-premise řešení, ale jsou situace, kdy že zbytečné chodit s kanonem na vrabce. A k tomu směřoval ten dotaz, jak nejlépe zabezpečit toto řešení na levném VPS serveru, kde není možné mít okolní infrastukturu. Čili rada jít tam, kde jí budu mít je hezká, ale na to jsem se neptal. Ptal jsem se na maximální možné zabezpečení v rámci dané situace

    Děkuji.

     
    čtvrtek 26. září 2019 10:19
  • Mám barák. Nemá plot, nemá dveře, ale já ho chci co nejlépe zabezpečit. Rady, že si mám postavit plot a koupit dveře mě nezajímají. Asi tak no . . .

    Ještě jedna věc - marně přemýšlim, jaký smysl má SQL server vystrčený do internetu? U RDP to ještě chápu, ale u DB serveru?


    BB

    čtvrtek 26. září 2019 10:59
  • Mám barák. Nemá plot, nemá dveře, ale já ho chci co nejlépe zabezpečit. Rady, že si mám postavit plot a koupit dveře mě nezajímají. Asi tak no . . .

    Ještě jedna věc - marně přemýšlim, jaký smysl má SQL server vystrčený do internetu? U RDP to ještě chápu, ale u DB serveru?


    BB

    Na serveru běží apka s sql. Do tohoto sql potřebuje mít přístup další apka z lokálního prostředí.

    Jinak to srovnání s bárakem je fajn, ale nemyslím si, že je přesné. Barák bez dveří a oken to by odpovídalo spíše serveru s vypnutím firewallem. Takže se možná jedná o barák co má základní okna a dveře. A nepotřebuji nutně, aby z něj rovnou byla nedobytná banka. 

    čtvrtek 26. září 2019 11:11
  • "Do tohoto sql potřebuje mít přístup další apka z lokálního prostředí.": Site-To-Site VPN.

    BB

    čtvrtek 26. září 2019 11:15
  • "Do tohoto sql potřebuje mít přístup další apka z lokálního prostředí.": Site-To-Site VPN.

    BB

    Ten sql je podružná věc, to teď neřeším, klidně to lze řešit taky přesunem apky do toho cloudu. 

    Ten prvotní dotaz se týkal zabezpečení po instalaci DC. Čili, ze bych zavřel komplet vše kromě rdp do internetu. Jestli to neovlivní chod vlastního serveru. Asi nezbyde nic jiného než to otestovat. Abych nemusel řešit okna a dveře :-)))))

    čtvrtek 26. září 2019 11:20
  • Jen by měl zajímalo jak to mají řešené všechny ty firmy co poskytují třeba online účetnictví, ke kterým přistupuje uživatel napřímo přes RDP nebo RemoteApp. Taky není žádná VPN....většinou.
    čtvrtek 26. září 2019 11:22
  • Jak to dela hosting ucetnitvi? Uplne standardne.

    Tj ma lokalni sit, v ni na oddelenych serverech role DC, SQL a RDS. Do internetu publikuje pouze SSL port RD Gatewaye.

    Vysledkem je bezpecne pripojeni k RDP k publikovane aplikaci, ktera komplet bezi "uvnitr", a interne komunikuje s DC a SQL. Zakaznik dostane RDP soubor, na ktery poklepe.

    Proste standardni reseni.

    Tj neni z internetu videt nic, nez jen SSL RDGW, ktera idealne bezi v nejake DMZ opet na oddelenem stroji = utocnik/DOS utok atp. poskodi pouze tento jeden server.

    Lacine reseni (to ktere si navrhnul) sice muze fungovat, ale nebude standardni, nebude bezpecne, budes resit nestandardni situace.

    čtvrtek 26. září 2019 11:34
  • Na serveru běží apka s sql. Do tohoto sql potřebuje mít přístup další apka z lokálního prostředí.

    Pořád to není dobrý nápad. SQL prostě do internetu nepatří vystrčit. Není to bezpečné. Bude to vůbec šifrované spojení, umí vůbec ten SQL i aplikace šifrované spojení nebo to chceš posílat přes internet v čitelné podobě?

    Tady je opravdu řešením jedině VPN nebo umístit aplikaci do stejné sítě jako SQL. A záleží na aplikaci a typu provozu, ale pokud SQL je někde bůhví kde, tak ta aplikace ve výsledku nejspíš bude děsně pomalá.

    Jinak řečeno, SQL i aplikaci dej do jedné lokální sítě. Z důvodu bezpečnosti i výkonu.

    čtvrtek 26. září 2019 14:55
  • Na serveru běží apka s sql. Do tohoto sql potřebuje mít přístup další apka z lokálního prostředí.

    Pořád to není dobrý nápad. SQL prostě do internetu nepatří vystrčit. Není to bezpečné. Bude to vůbec šifrované spojení, umí vůbec ten SQL i aplikace šifrované spojení nebo to chceš posílat přes internet v čitelné podobě?

    Tady je opravdu řešením jedině VPN nebo umístit aplikaci do stejné sítě jako SQL. A záleží na aplikaci a typu provozu, ale pokud SQL je někde bůhví kde, tak ta aplikace ve výsledku nejspíš bude děsně pomalá.

    Jinak řečeno, SQL i aplikaci dej do jedné lokální sítě. Z důvodu bezpečnosti i výkonu.

    Díky za info. Spojení na SQL z lokálu je čistě administrační, žádná velká data netečou, ty jsou potřeba z té aplikace v cloudu. Ale asi není problém to řešit celé v cloudu a nic nevystavovat.

    Jen potřebuji v rámci možností zabezpečit ten terminal server s DC rolí s prostředky jaké jsou k dispozici, tedy nativní prostředky Windows Serveru 2016. Nic víc. Zkusím zablokovat vše kromě RDP a uvidím jak se to bude chovat. V každém případě ataky z netu tam jsou v logu v podstatě nonstop.

    čtvrtek 26. září 2019 15:05
  • DC s RDS roli je opet nepodporovany scenar - opet reseni lacineho muze.

    Jak bylo napsano - pravdepodobne to dokopes k cili, ale hrozne se nadres a nikdy to nebude tak bezpecne, jak by melo/mohlo


    pátek 27. září 2019 6:08
  • Děkuji za všechny ty přínosné podněty. O víkendu jsem k tomu dohledal spoustu informací, upravil nastavení serveru, implementoval blokovací automat a hlavní problémy jsou asi vyřešeny.

    Když to shrnu. Zaměňuje se tu fráze "nepodporovaný scénář" pravděpodobně s frází "nedoporučený scénář". Instalace RDS na DC opravdu nebyla podporována standardními nástroji do verze serveru 2012 a to do určité doby. Při pokusu o instalaci role RDS průvodce skončil s chybou, že to není možné na DC. Toto řešila aktualizace KB2871777, která přidala možnost instalace RDS na DC. Z nepodporovaného řešení se tak stalo řešení podporované a to nadále platí i pro další verze Windows (2016,2019). Můžete tedy maximálně hovořit o nedoporučovaném scénáři, což v případě on-premise nebo hybridního řešení je zcela pochopitelné.

    V případě, když se k DC serveru nebude připojovat žádná jiná stanice ani server (jedná se o VPS v cloudu), lze zablokovat komplet všechny příchozí porty vyjma specifického portu pro RDP. Toto jsem otestoval, je to funkční. Co potřebuji funguje.

    RDP - dle informací od MS se jedná o bezpečný protokol, který lze prolomit pouze použitím hrubé síly. K bezpečnému provozu se váže několik doporučených nastavení (nastavení účtů a ověřování, bezpečná hesla, porty, aktuální systém). K tomu jsem implementoval funkci, která automaticky blokuje na firewallu všechny IP, ze kterých přicházejí útoky.

    Před změnou nastavení jsem v logu zabezpečení měl mraky ataků každou vteřinu, kdy byl zaznamenán neúspěšný pokus o přihlášení k RDP. Během jednoho dne to dělalo i stovky tisíc pokusů. Po změně v nastavení je tento počet za posledních 6 hodin 0, čímž jsem se dopracoval asi k tomu co jsem potřeboval v rámci dané situace.
    neděle 29. září 2019 16:13
  • To že to technicky (teď/asi) funguje ještě neznamená, že je to podporované. Ten scénář je stále nepodporovaný. Nepodporovaný znamená, že není testovaný vývojáři, není ověřena a zaručena jeho správná funkcionalita a kompatibilita a nelze k tomu oficiální cestou získat podporu ze strany MS. Tohle znamená nepodporované. Když s tím tedy budou nějaké problémy, nikdo ti s nimi nepomůže. A protože tuto kombinaci MS netestuje a neověřuje její funkčnost, může se klidně stát, že dřív nebo později se nějaké problémy objeví. Minimálně při inplace upgrade na vyšší verzi je to velmi pravděpodobné - nehledě na to, že inplace upgrade DC by jsi vůbec dělat neměl. Miroslav má tedy pravdu, je to nepodporované (a samozřejmě tedy také nedoporučené).

    Co se týče bezpečnosti RDP, tak ano, spojení je šifrované. Ale to je tak celé co se týče bezpečnosti. Problém jsou zranitelnosti, které se pro RDP pravidelně objevují a velké množství úspěšných útoků na firemní infrastrukturu je právě přes RDP (spolu s SSH a SMB) vystrčené do internetu. Tohle není nějaký teoretický strašák, tohle je realita. Jak zajistíš, že uživatelé budou mít pouze bezpečná hesla? Jak zajistíš, že uživatelé stejná hesla nepoužívají i na jiných službách, ze kterých potenciálně mohou uniknout, viz https://haveibeenpwned.com/ a útočník je pak jednoduše použije i na to vystrčené RDP? Budeš řešit vícefaktorové ověřování? Pokud fakt na tomto velmi nebezpečném (a tedy velmi nezodpovědném) přístupu trváš, tak na firewallu omez IP adresy, ze kterých se lze na RDP připojit, tj. řeš blokaci opačným způsobem než teď - vše bude zablokované a jen pár vybraných IP povol namísto vše povolené a jen pár známých vybraných IP blokuješ. Dále pečlivě a okamžitě instaluj všechny bezpečnostní aktualizace systému včetně následných restartů OS - pro útočníka není nic jednoduššího, než využít známou zranitelnost systému, na kterou jsi ale zatím neaplikoval patch. A také všem účtům vygeneruj silná hesla a nedovol uživateli heslo změnit - aktuální doporučení pro silná hesla je alespoň 32 znaků, náhodná kombinace velkých/malých písmen, čísel a speciálních znaků.

    • Navržen jako odpověď Michal13 pondělí 30. září 2019 5:39
    neděle 29. září 2019 18:25
  • Děkuji za velmi přínosný příspěvek. 
    pondělí 30. září 2019 5:39
  • Tak aby sis prestal delat iluze o bezpecnosti RDP portu v internetu. Opet dalsi zaranitelnot umoznujici spustit kod. https://msrc-blog.microsoft.com/2019/08/13/patch-new-wormable-vulnerabilities-in-remote-desktop-services-cve-2019-1181-1182/

    Ted ty sam zamenujes pojem bezpecny protokol s pojmem bezpecna sluzba. Protokol RDP je bezpecny, ale jeho "serverova strana" nikoliv.

    Opravdu mame z nasi praxe mnoho zakazniku, kterym se nekdo naboural do systemu prave pres objevenou vulnerabilitu RDP sluzby, kdy zakaznik nemel spravny patch, protoze obvykle servery nepatchujete  kazdy den.

    Proto VSEM na sim zakaznikum DURAZNE doporucujeme nepublikovat RDP port primo a to ani na jinem portu nez je defaultni. To, ze se ti zatim nic nestalo, povazuj za stesti.

    Ad RDS na DC.
    Me se fakt nelibi, ze by standardni uzivatel mel moznost pracovat na DC. Ale kdo chce kam....

    Nema smysl pokracovat v teto debate. Ty sis vymyslel reseni a v podstate si chtel jen potvrdit jeho spravnost, coz tu nikdo neudela.



    pondělí 30. září 2019 6:17