Dotaz: Zabezpecenie intranetu (Apache + PHP + MySQL)

[needlinux]

Pozdravujem vsetkych,

riesim otazku ohladne zabezpecenia pristupu do firemneho intranetu (dochadzka, uctovnictvo, riadenie projektov...) zalozeho na vlastnej aplikacii PHP5. Ako web-server je pouzity Apache2, databaza je MySQL5. Prihlasovanie do intranetu sa robi cez uzivatelske meno a heslo.

Vsetko bezi na jednom serveri pod SuSE10, ktory je umiestneny na vnutornej sieti. Momentalne sa do intranetu pristupuje iba z vnutornej siete cez port 80. Ak sa potrebujem dostat do intranetu cez internet, prihlasim sa najskor do vnutornej siete cez VPN.

Teraz ale potrebujem umoznit pristup aj externym pracovnikom z domacich pocitacov (cca 10 osob), cize uvazujem o sirsom spristupneni intranetu z vonku. Mam nasledovne moznosti, ale neviem s istotou posudit mieru bezpecnosti pre jednotlive sposoby:

1. Na firewalle jednoducho presmerovat vsetky poziadavky prichadzajuce na porte 80 na web-server na vnutornej sieti. Prihlasovanie z vonku by bolo zadanim verejnej IP: https://123.123.123.123
2. Na firewalle otvorim iba konkretny port, napr. 9898 a vsetko z neho presmerujem na vnutorny web-server na port 80. Prihlasovanie z vonku by bolo v tvare: https://123.123.123.123:9898
3. Kazdemu klientovi vytvorim pristup do VPN siete a vysvetlim postup instalacie klienta.
4. Do prihlasovacieho formularu pridat opis alfanumerickeho obrazku pre eliminaciu utokov robotmi na webe.
5. Celu aplikaciu premiestnit na virtualny server, ktory bude zaveseny na chrbticovej sieti u nejakeho poskytovatela tejto sluzby. K tomuto rieseniu chcem pristupit aj z hladiska lepsej dostupnosti intranetu z vonku aj za cenu spomalenia pristupu z fir. LAN.

>> Moje nazory:

• do tretej moznosti sa mi velmi nechce. Jednak je to pracne a potom sice zabezpecim intranet, ale zaroven otvorim cestu do vnutornej siete zo sukromnych pocitacov.
• najviac uvazujem nad kombinaciou bodov 2+4+5, ale neviem presne akych bezp. rizik by som sa mohol v tomto pripade obavat.

Dakujem za Vase rady a nazory.

---

---

Odpovědi

[Filip Jirsák]

Záleží na tom, jak dobře je ta aplikace a server zabezpečený. Variantu 2 bych zamítl rovnou, nezanedbatelný počet lidí se na web na nestandardním portu nedostane. Varianta 4 je zbytečná, nic tím nevyřešíte. Varianta 3 znamená, že k serveru nadále budou moci přistupovat jen vaši lidé, takže teoreticky nemusí být tak dobře zabezpečen (můžete bezpečnost ošetřit třeba organizačně) – je dobré si ale uvědomit, že podle výzkumů většina útoků pochází zevnitř. Varianta 1 a 5 znamená vystavit server na internetu, takže jak server tak aplikace musí být zabezpečená. Zadávání IP adresy bych se úplně vyhnul, vytvořte pro ni nějaký DNS záznam (vaše firma nejspíš už nějakou doménu má, takže by neměl být problém do ní přidat jeden další záznam).

[needlinux]

Neviem presne ako utoky na web-servery prebiehaju, ale chcem aspon eliminovat moznosti. Umyselnych utokov z vnutra sa az tak velmi neobavam, organizacne toto osetrene mame. Skor sa obavam neumyselnych - napr. ak ma niekto na svojom sukromnom pc nejaky spyware a ten sa snazi ziskavat info v ramci vnutornej siete. Myslel som, ze utok zvonka zamerany na web-server sa standartne zacina cez port 80, takze som chcel nejake percento utokov odstranit prevadzkou na inom porte. Bod 4 sa mi zda ako vhodna zauzivana technika, ktoru vidim aj na velkych webovych projektoch - mozno to ale vyznam nema, neviem. Pridat dalsi zaznam do DNS nieje problem, ak by to zvysilo otazku bezpecnosti spravim to urcite, ale asi je to iba otazka komfortu. Otazka zabezpecenia aplikacie je samozrejme vzdy diskutabilna. Aplikacia je postavena z Open-Source projektov, ktore su upravene pre nase konkretne potreby. Su v nej vyuzivane vsetky aktualne dostupne bezpecnostne techniky poskytovane v PHP5 (napr. pristup na kazdu stranku kontrolou session) ale zachytil som info, ze PHP nieje z hladiska bezpecnosti na najvyssich rebrickoch. Server bude jednoucelovy, bude na nom firewall a bude mat otvoreny iba jeden port pre web a povedzme ak bude vzdialeny tak aj port 22.

[Filip Jirsák]

Nevím o tom, že by byla v poslední době v serveru Apache nějaká bezpečnostní díra, která by umožnila třeba v kontextu serveru spustit útočníkův kód. Útoky jsou tedy v drtivé většině případů vedeny na aplikaci, která na serveru běží – a tomu je nutné přizpůsobit zabezpečení. Pokud jste si jist, že se aplikací lze pracovat pouze po přihlášení a přihlášení je bezpečné, můžete server vystavit na internetu. Pokud je ale možné, že útočník může s aplikací nějak manipulovat i nepřihlášený, nebo pokud není přihlášení bezpečné (je možné odposlechnout heslo, je možný únos session apod.), pak byste server na internetu teď vystavovat neměl – a je pak otázka, zda je lepší opravit aplikaci, nebo řešit přístup k serveru jen pro oprávněné uživatele.

Automatické útoky na port 80 se týkají známých aplikací jako WordPress apod. Pokud vy máte svou aplikaci, útočník by útočil konkrétně na ni a určitě by věděl i to, že běží na jiném portu.

[needlinux]

Na aplikacii mi napr. dost vadi, ze heslo pre pristup do DB je uvedene v txt subore config.php. Toto je bezny postup, ale bezpecne to urcite velmi nieje. Ak niekto ziska pristup do DB, automaticky ma pristup aj k session a prihlasovacim udajom a somozrejme aj datam samotnym . Trochu som prechadzal rozne aplikacie tohoto druhu, ale vsetky to maju riesene takto a podobne, neviem ci je aj ina moznost. Citanie tohoto suboru musi byt samozrejme povolene aspon pre uzivatela, ktory spustil aplikaciu - najlepsie asi jednoucelovy uzivatel. Najviac sa ale obavam utokov takeho typu, ze niekomu na domacom pocitaci bude bezat na pozadi spyware, ktory odchytava prihlasovacie mena a hesla a posiela ich niekam - nikto netusi kam. Ak som veci spravne pochopil, tak podla Vasho nazoru sa nahodneho utoku na web-aplikacie netreba velmi obavat, skor presne zameranych utokov...

[pht]

Pokud je heslo v souboru config.php tak ten soubor je snad na serveru a má na něj přístup jen webová aplikace, nikoliv uživatelé?

Jinak uchovávání hesla k db pro web-based (i jiné) aplikace je běžný postup. Je úplně jedno, jestli je v .php nebo zakódován v .exe, podstatné je, že aplikace má absolutní přístup k datům v db, a kontrolu přístupových práv uživatelů (je-li) provádí sama. Jednoduchý útok na tuto architekturu je takový, že počkáme až se aplikace připojí a pak převezmeme spojení (nebo přes debugger převezmeme kontrolu nad aplikací). Pak si můžeme dělat v DB co chceme.

Ošetřit se to dá tak, že přístupy jsou definované na úrovni databáze a aplikace do db přistupuje jako uživatel, který se do ní přihlásil. Pokud má databáze solidní systém zabezpečení, je automaticky stejně dobře zabezpečena i aplikace. Bohužel většina komerčního SW takto nefunguje.

Analogie prvního principu je program "rm" běžící pod rootem s vlastní logikou kdo co smí; druhý princip je běžné použití rm pod uživatelem a právy na souborovém systému.

[needlinux]

config.php je samozrejme na strane serveru. Cita sa z neho v momente prihlasovania aplikacie do DB, ktora vystupuje pre DB ako uzivatel s vlastnymi pravami. Tieto pristupove prava su obmedzene na urovni bezpecnostnych technik MySQL - pomocou tabuliek v DB mysql. Trosku sa mi ale nepozdava to, ze prihlasovacie udaje do DB su ulozene v citatelnom formate v obyc. txt subore. Nepoznam postupy utokov, ale ak by som chcel ziskat pristup k DB skusal by som najst najskor subory tohoto typu. Tuto bezp. politiku som pochopil tak, ze ak sa niekto dostane az k suborovemu systemu serveru tak uz nieje co velmi chranit.

[Šangala]

Reaguji jen na bezpečnost conf. souboru
Je to naprosto běžný postup. I kdyby se aplikace hlásila certifikátem k DB musí mít certifikát přístupný, tudíž jakmile získám kontrolu nad aplikací získávám kontrolu nad prostředky, s kterými manipuluje.
Je třeba nastavit takové oprávnění ke konfiguračnímu souboru aby nebylo možné jej nijak zobrazit většinou tzn.:

• Přístup do databáze je jen na jednoho (případně více, pokud s tím aplikace počítá např pro READ a WRITE operace) uživatele a přístup pro něj je povolen jen z IP adresy PHP serveru (např localhost)
• Konfigurační soubor je umístněn v adresáři, který nemá povolen přístup z venku (by konfigurace Apache) (většinou nelze realizovat na hostinzích)
• Složka obsahuje soubor .htacess, kde je povolen přístup jen z localhost (doporučil bych to i když je splněna předchozí podmínka - záložní ochrana).
• Disková oprávnění tak, aby se na ten soubor nedostal nikdo krom uživatele, na kterého běží PHP a to jen s oprávěním ¡READ! (což je i VELMI vhodné na zbytek souborů PHP),bo toto zajistí:
  1. že nikdo nemůže číst přístupové informace k DB
  2. chyba či úmysl v aplikaci (nebo i jiné provozované ve stejném prostoru) nemůže změnit svůj vlastní kód
• Konfigurační soubor a připojení do db musí být udělán tak, aby jej nebylo možné prostředky PHP/Apache zobrazit, řádně označen jako kód php <?php ... ?>.
  Pokud se jedná opravdu o textový soubor ne PHP script a heslo se z něj čte pomocí čtení ze souboru a soubor neobsahuje na začátku <?php a konci ?>, tak je to dobře, jen tehdy pokud je to absolutně mimo prostor, na který se dostanete z venku, mimo např. /var/www/htdocs
• Pozor na include configuračního souboru jinou aplikací na serveru, většinou to není ochráněno, tudíž i kompromitace jiné aplikace a znalost struktury umožní kompromitovat další aplikace.
  Lze tomu zamezit obskurním opatřením, v configuračním souboru kontrolovat existenci a obsah nějaké proměnné specifické pro aplikaci a v aplikaci ji předem nastavit, jinak vyvolat exit(); (v případě že se jedná o heslo v php souboru v promněné)
• Pokud se jedná o Kritickou aplikaci aplikaci, provozovat ji jen přes https a je možno vytvořit MD5 či SHA1 otisk aplikace či jednotlivých souborů a pravidelně je kontrolovat, viz moje patička :) .. a v tomto případě běžný ftp přístup k aplikaci je kravina.
• Slušnost programátora je, že heslo i hned po přihlášení do DB zapomene/přepíše/unset-ne, tím se chrání sám před sebou

PS: jednotlivé kroky zvyšují ochranu, není nutné splnit vše, ale jo tak asi všechno co si můžete zajistit.

[needlinux]

Dakujem za vycerpavajuce informacie

[pht]

To je sice hezké, ale je to mimo moji pointu. Aplikace sama o sobě by neměla mít žádný účet v databázi, natož takový, který je nadmnožinou všech uživatelů dané databáze. Aplikace by měla používat přístupová oprávnění, které jí nadiktuje až uživatel.

Příklad (aplikace Drupal): V mysql existuje účet "drupal" který má přístup do všech dat drupalu. Uživatelé drupalu a jejich práva jsou vedeni v interní tabulce a omezeni logikou PHP skriptů.

Což je naprosto běžný postup který je špatně.

Lepší příklad (aplikace phpmyadmin) je nadefinovat uživatele aplikace a jejich přístupy už na úrovni DB. Nemusím řešit úschovu "master" hesla pro účet "drupal" a nemusím v PHP řešit přístupová práva. Nemusím řešit omezení databáze na IP adresu serveru. Uživatel bude mít naprosto stejná práva pokud se přihlásí přímo do databáze nebo pokud se přihlásí na webové stránky.

[needlinux]

ako potom zabezpecit bezpecny pristup z aplikacie do DB mysql na prepisanie pristupovych tabuliek - vytvorenie noveho uzivatela. Alebo uzivatela pridavat do DB mimo standartnu aplikaciu?

[pht]

ako potom zabezpecit bezpecny pristup z aplikacie do DB mysql na prepisanie pristupovych tabuliek - vytvorenie noveho uzivatela.

To úplně nechápu, vždyť jeden z uživatelů může mít právo zakládat jiné uživatele. Optimálně pouze zakládat a přiřadit právo k datům třeba zase jiný uživatel (ten co je za data odpovědný).

[Šangala]

Ano je to je jeden z modelů, ale ne vždy vhodná až správný.
Pokud mám intranetovou aplikaci, a třeba i centrální autentifikac/autorizaci, tak nebudu definovat každého uživatele v databázi a udržovat mu přihlašovací údaje, na úrovni DB (prakticky by to znamenalo, že by se nikdy nezměnily :) ).
Pokud aplikace pracuje s daty, na které má oprávnění 10 lidí tzn. 10× přihlašovací údaje, které jsou pseudo-veřejné a měli uživatelé (pro mně hrozivý případ) přístup přímo k DB či prostředky manipulující s DB bez předem stanovené veřejné aplikační vrstvy, tak je výrazně vyšší (minimálně 10×) šance kompromitace těchto dat.
Ano to co píšete, je možné k vytvoření rolí (skupin oprávnění) a uchovávat na straně aplikace master heslo či hesla, třeba i pro každou roli zvlášť.
Ale model, že uživatel k DB (db serveru) má přímý přístup není nic-moc :)

[pht]

centrální autentifikac/autorizaci

Můžete na LDAP (nebo co máte) napojit autorizaci přístupu do db. MySQL to sice neumí, ale neříkám že MySQL je pupek světa co se týče bezpečnosti.

pro mně hrozivý případ ... že uživatel k DB (db serveru) má přímý přístup

No vidíte, to je to Vaše uvažování (patrné i z jiných příspěvků): Centrální heslo aplikačního serveru je nejvíc střežené tajemství, předpokládá se, že každý by raději zemřel než měl slabé heslo, každá aplikace musí projít auditem a mít certifikát nevinnosti atd. A jakmile se něco z těch předpokladů poruší tak se vše hroutí.

Moje aplikace tato představa neděsí. Pokud uživatel obejde aplikační server, tak třeba přijde o grafické rozhraní zadávacích formulářů, ale rozhodně nebude mít možnost napáchat škodu nebo číst nepovolená data. I pokud se stane, že znásilní PHP skript a dostane shell na serveru, tak pořád nemá možnost číst data v databázi.

[Šangala]

Ad. LDAP, ano mám na jednom LDAP server :)
Ad. Everest, MySQL není pupkem světa, ale předmět dotazu je jasný :)
Ad. Centrální heslo, kde ? co ? jak ?, každá aplikace má vlastní každý server má vlastní (je to jen jiný pohled na bezpečnost, Vám hesla kolují světem a je jich hodně, ale zajišťují oprávněnost požadavku na každé úrovni, a někomu jedno silné skryté heslo, které nikde nekoluje).
Ad. Audit, tak to zrovna ¡ne! :), audit neznamená, že to má certifikát od kohosi, ale pokud vystavuji aplikaci s omezeného kontrolovaného prostředí do vnějšího prostředí bez kontroly, tak si ten audit (chcete-li kontrolu) udělám abych zjistil jestli tam není nějaké potenciální riziko (použil jsem termín audit, bo jsem vyrozuměl, že tazatel není pro tuto oblast kován).
Ad. hroutí právě naopak hroutí, se jen ta aplikace - pokud je to nastaveno správně
Ad. Váš model (je jeden z modelů), ale je si třeba uvědomit, že tím musíte hlídat bezpečnost všech článků - DB server musí být odolný vůči vnějším útokům.
Ad. děsí --- aplikace to neděsí, ale co správce ? :) {není třeba odpovědi - to je joke}

Ale naše debata je o různých modelech bezpečnosti a je asi zbytečná, každý má nějaké výhody a nevýhody, stejně jako tlustý/tenký klient databáze je úložišě nebo zaručuje 100% integritu.

... mně neděsí to tak udělat, ale děsí mně to udržovat s větším množstvím uživatelů a aplikací různých autorů a hlavně hlídat bezpečnost všech serverů, zůstaňme každý u své myšlenky a každý ať se rozhodne co je pro něj lepší.

Všimněte si že připouštím více uživatelů na DB (read/write) a těch může být více (zmiňované role) - je to další stupeň bezpečnosti, eliminující jisté chyby v aplikaci.

Ruku na srdce jste schopen nastavit jednotlivé uživatele na velkém projektu přesně a do detailu tak aby měli oprávnění přesně na každý sloupec databáze (struktura DB se pak řídí jen bezpečnostním modelem)?
Myslím, že ne, a nakonec se stejně sáhne k aplikační definici oprávnění. Rozlišit oprávnění na data a současně na procesy a akce na úrovni DB vyžaduje mít nastavenu 100% aplikační logiku v DB na vše VIEW a funkce metody a trigery. Samozřejmě je to cesta, a perfektní, ale realizace je mnohem náročnější a zrovna na intranet(záleží co to obnáší) mi to nepřipadne vhodná.

[pht]

Vlákno bylo přesunuto do samostatné diskuse.

[H0ax]

Nedovedu si představit, jak bys chtěl toto řešení provozovat s tisíci uživateli a stovkami databází v jednom sql serveru.

[pht]

Jak s tím souvisí objem?

[H0ax]

Pokud mám systém, kde na jednu db připadá jeden user, který jí vlastní a v ní jsou definována práva pro danou aplikaci, tak je to pro mě jednodušší než nekontrolovaně se množící useři pro tuto db. Nechtěl bych vidět mysql.user tabulku na systému, kde je 100 phpbb fór, každé o 10000 userech a to není nic neobvyklého.

[pht]

Já na tom nevidím nic špatného. Pokud mysql nezvládne tabulku o milionu řádků tak použijte něco jiného. Takhle tam těch milion řádků máte taky, ale overhead jejich zpracování je podstatně vyšší.

A až někdo exploitne to phpbb a smaže všechny posty tak prostě napíšete na web "hehe pardon", opatchujete to a jede se dál. Když někdo exploitne účetnictví a udělá tam bordel, nebo projektová data k tomu na čem Vaše firma stojí tak to tak jednoduché nebude.

[Dalibor Smolík]

Když někdo exploitne účetnictví a udělá tam bordel, nebo projektová data
Zálohovat, zálohovat ..

[pht]

Záloha proti ukradeným datům prodaným konkurenci nebo firemním penězům na cizím účtě moc nepomůže :)

[pht]

Tieto pristupove prava su obmedzene na urovni bezpecnostnych technik MySQL - pomocou tabuliek v DB mysql.

Viz rozlišení účtu pro aplikaci a účtů pro uživatele.

Nepoznam postupy utokov, ale ak by som chcel ziskat pristup k DB skusal by som najst najskor subory tohoto typu.

Jak jsem říkal nejjednodušší je počkat až se aplikace autentizuje a pak nějakou metodou převzít velení. Pokud aplikace běží přímo na Vašem PC tak je to triviální, pokud na ni přistupujete přes prohlížeč tak můžete někam zkusit procpat PHP nebo SQL kód. Minimálně jedna taková díra tam někde bude a pak už to máte v hrsti.

Tuto bezp. politiku som pochopil tak, ze ak sa niekto dostane az k suborovemu systemu serveru tak uz nieje co velmi chranit.

Ale je.

[Jendа]

od 4 sa mi zda ako vhodna zauzivana technika, ktoru vidim aj na velkych webovych projektoch - mozno to ale vyznam nema, neviem.

Kde třeba? Jak by to mělo zvýšit bezpečnost? Nechápu…

Hlavně až budete nastavovat HTTPS, tak nezapomeňte uživatelům rozdistribuovat otisky certifikátu (případně root certifikátu firemní CA, pokud máte).

[needlinux]

napr. https://www.setup.sk Vyznam vidim v tom, ze automat moze opakovane skusat prihlasovacie meno a heslo, ale nevie opisat znaky z obrazku. Samozrejme ze pocet pokusov sa da limitovat, ale aj toto je zrejme jeden z moznych sposobov ochrany.

CA nebude problem

[Jendа]

Spočítej si, kolik pokusů za sekundu dokáže automat udělat po síti, a kolik pokusů je potřeba k rozlousknutí 8znakového hesla…

[Šangala]

Moc pokusů :), ale co když hesla neprojdou "Slovníkovým útokem", jakože hesla typu Marenka241270, má velké množství běžných uživatelů, matematicky sice silné heslo, ale přes slovníkový útok, když Mařenku znám nepotřebuji ani robota :).
Nevím jestli je tento způsob s obrázkovým kódem nejvhodnější, ale nějak hlídat či omezovat počet neplatných pokusů bych nepodceňoval.

[Vantomas]

Ja bych zvolil pouziti VPN. Externi pracovniky by slo dat do jine site, nez je zbytek vnitrni site, a pak neni problem je dostatecne zabezpecit ve firewallu jen na zaklade rozsahu IP.

Nevim co pouzivate za VPN, ale na vetsinu VPN klientu jde vyrobit primo instalacni balicek vc. certifikatu nebo predvyplnenych pristupovych udaju, pujde pak i lehce nekomu zakazat pristup jen na strane VPN serveru zakazanim jeho pristupu.

U externich lidi clovek nikdy nevi, co maji v pocitaci za bordel a je to mnohem slozitejsi uhlidat, zda neco v pocitaci maji nebo ne, klidne by se mohlo stat, ze se dostanou prihlasovaci udaje do spatnych rukou a v pripade spatne napsane aplikace muze byt problem. Zvlast, kdyz bude aplikace volne pristupna z Internetu.
Pri pouziti VPN je alespon v ceste vice prvku, ktere je potreba prekonat.

Dalsi moznosti je presmerovat verejnou IP na vnitrni webserver, ale mozna doplnit o filtr IP adres, aby se tam nedostal kazdy, ale jen povoleni lide, ale zde je zase problem s tim, ze se nekterym muzou menit IP adresy a ti lide se muzou pohybovat i po vice mistech s ruznyma adresama.

[needlinux]

Pouzivame OpenVPN. Instalacia na Win klientovi nie je zlozita, asi by ju zvladol kazdy sam. Ak to pojde este zjednodusit bude to urcite fajn - vacsinou su to uzivatelia iba so zakladnymi znalostami pc. O filtrovani IP adries som uvazoval, ale staticku asi bude mat doma malokto.

[Vantomas]

Tady je zdrojak (a nejake info) pro NSIS, pro vytvoreni vlastniho instaloru.

[pht]

Co se týče zabezpečení přístupu na server, IMHO je nejjednodušší použít HTTPS, případně jej podpořit klientskými certifikáty. Přesun na nestandardní port může být výhodný; případné problémy s tím, že se tam jeden zaměstnanec nedostane lze vyřešit individuálně.

VPN je pro takovýto druh přístupu dost těžkopádné a navíc celá myšlenka VPN je lehce proti filozofii internetu. Typicky se může stát, že Váš zaměstnanec bude mít na své domácí síti nebo na síti v hotelu stejný privátní rozsah, jako máte ve firmě, a budete to muset řešit. Proto je metodicky lepší řešit zabezpečení jednotlivých služeb zvlášť (SSL) nebo mít zabezpečení komunikace počítač-počítač pomocí transport režimu IPSec.

Je potřeba ošetřit/odlišit přihlašování z domova verzus z veřejných míst (kavárny). V domácím prostředí je hrozba malware, zcizení přihlašovacích údajů, nebo hijackingu přihlášeného sezení poměrně malá, ale na veřejných místech to může být kámen úrazu. Tomu můžou napomoct zmíněné klientské certifikáty, nebo spíše HW tokeny (od renomovaných výrobců, žádné "hyper security" krámy za 10 korun).

Dále přehlížíte jednu podstatnou věc a to že zpřístupněním interní služby zvenku si děláte díru do interní sítě. Bude-li ve Vaší aplikaci PHP chyba, bude mít v lepším případě přihlášený a v horším případě i nepřihlášený uživatel možnost použít server pro invazi do vnitřní sítě. Pokud nemáte vnitřní síť zabezpečenou proti sobě sama (což je případ drtivé většiny firemních sítí), dejte alespoň server do DMZ, odkud nebude mít libovolný přístup do interní sítě.

Pokud aplikace bude sbírat data z dalších zdrojů na síti, budete muset nějak ošetřit případné probourání útočníka i tam (např. triviálně telnet na docházkové terminály, atd).

Podobným principem, pokud se rozhodnete pro server hosting/housing/VPS na páteřní síti, budete muset nějak vyřešit bezpečný přísun dat na server z Vaší firmy. V tomto případě může v případě probourání na server tento kanál být zneužit opět pro přístup do Vaší interní sítě.

[needlinux]

Vy vidite v pouziti nestandartneho portu nejaky bezp. zmysel?? Podla skorsej diskusie to velky vyznam nema.

Pristup z verejnych miest by som chcel obmedzit firemnymi pravidlami - nieje to potrebne z hladiska vyuzivania intranetu. Potrebujem zabezpecit napr. moznost pracovat v uctovnictve z domu, alebo projektantantovi zpristupnit spravcu projektov ked kresli doma...

Co sa tyka prenosu dat do firmy bude pouzita tiez VPN siet, ale urcite na osobitnom subnete. Bolo by potom zrejme tiez vhodne presuvat data do DMZ, odkial si ich bude brat aplikacia z vnutornej siete...? Nieje to uz privelmi paranoidne?

[pht]

Vy vidite v pouziti nestandartneho portu nejaky bezp. zmysel?? Podla skorsej diskusie to velky vyznam nema.

Ano vidím, bude Vás obtěžovat o 100% automatických útoků méně a to se vyplatí.

Pristup z verejnych miest by som chcel obmedzit firemnymi pravidlami - nieje to potrebne z hladiska vyuzivania intranetu.

Tak pak kontrolujte logy, zda to lidé dodržují. A i tak jsou klientské certifikáty dobrý nápad.

Co sa tyka prenosu dat do firmy bude pouzita tiez VPN siet, ale urcite na osobitnom subnete. Bolo by potom zrejme tiez vhodne presuvat data do DMZ, odkial si ich bude brat aplikacia z vnutornej siete...? Nieje to uz privelmi paranoidne?

Na kterou větu jste tímto reagoval?

[needlinux]

Co sa tyka prenosu dat do firmy bude pouzita tiez VPN siet, ale urcite na osobitnom subnete. Bolo by potom zrejme tiez vhodne presuvat data do DMZ, odkial si ich bude brat aplikacia z vnutornej siete...? Nieje to uz privelmi paranoidne?

Na kterou větu jste tímto reagoval?

Na temu prenosu dat zo serveru napr. v ServerHostingu do firemnej LAN

[pht]

Ana. No. V podstatě musíte zajistit, aby se ten externí server mohl do interní sítě připojit jen tam, kam musí. To je ochrana prvního stupně.

Aplikací stejného postupu pak budete chtít aby ta místa, kam se připojil, měla taky co nejmenší působnost. (2. stupeň)

Ve výsledku můžete udělat to, že každou aplikaci/server ve Vaší síti nějak omezíte. Pokud si to nemůžete dovolit, omezte aspoň to, kam je přístup z toho venkovního serveru.

[needlinux]

Bezpecnejsie by potom asi bolo, keby aplikacie z vnutornej siete dotazovali DB pri vonkajsom web-serveri o aktualne data. FW by potom mohol vsetky poziadavky opacnym smerom zastavit

[pht]

To je samozřejmě dobrý nápad ale neřeší vše. Můžete kompromitovat server, počkat až se z firmy připojí sběrač dat, a pak mu místo očekávané odpovědi poslat něco hnusného, čímž třeba dostanete opět shell v interní síti. :) Nebo podobným způsobem zaútočit na prohlížeč uživatele ve firmě.

[needlinux]

Nie som odbornik na prieniky do cudzich sieti, takze si ani neviem velmi dobre prestavit tento utok v praxi. Znamena to, ze ak ja z vnutornej sieti poslem poziadavku na nejaky iny stroj za FW (napr. SQL dotaz na mysql demona), naspat sa mi vrati nieco, co podvrhne moj miestny shell a prihlasi sa trebars ako root?? Potom mam obavy, ci sa na takyto husty utok a jemu podobne budem vediet v dohladnej dobe pripravit.

[pht]

si ani neviem velmi dobre prestavit tento utok v praxi.

Je to stejnej princip jako když lezete na pochybné www stránky a do počítače se Vám dostane "vir". Požadavek vznesete vy a v odpovědi serveru je exploit na implementaci javascriptu (nebo čehokoliv) ve Vašem prohlížeči.

Stejně tak může SQL server exploitovat díry v SQL knihovně klienta. Roota tím dostane pouze pokud klient běží pod rootem, což není častý případ. Na druhou stranu root práva nejsou na spoustu věcí potřeba a/nebp se dají postupně získat.

Potom mam obavy, ci sa na takyto husty utok a jemu podobne budem vediet v dohladnej dobe pripravit.

Já Vám jenom popisuji možné scénáře, je na Vás, jakou jim přiřadíte pravděpodobnost, prioritu, atd. Jste to Vy, kdo ví cenu Vašich dat, zná lokální podmínky a lidi, umí posoudit, co je reálné, co je nebezpečné, co by bylo "jen" na obtíž, z čeho by byl průser, za co Vás "jen" vyhodí a za co se s Vámi budou soudit ;) Je daleko důležitější abyste se ochránil proti heslu "123", nebo proti telefonátu "Ahoj jsem na dovolené a potřebuju se dostat do účetnictví, prosímtě ..." než proti malware který někdo bude psát na zakázku na míru na Vaši síť.

[Dalibor Smolík]

Myslím si, že OpenVPN je dobrá volba. Certifikát je nainstalován u klienta, určitá bezpečnost je zajištěna. Já to tak praktikuji z domova nebo z chalupy, kdy se připojuji na firemní síť.

[NN]

HTTPS+ omezeni IP + omezeni portu, nebo VPN + omezeni portu..

NN

[Šangala]

Ad. omezeni IP, lze jen pokud uživatelé mají pevné veřejné IP

Poznámka: Pokud to bude bez šifrovaného tunelu, je bezpečnost přihlášení na intranet limitována kvalitou hesla a bezpečnostními prvky aplikace.
Některé prvky:

• Heslo musí mít minimálně 8 znaků (spíše více), velká/malá čísla - je třeba zajistit kontrolu hesel, případně jejich periodickou změnu, což mají uživatelé rádi
• Aplikace by měla umožňovat jen N pokusu (třeba 5) přihlášení na session za jednotku času (třeba 20min), jinak v tichosti odkazovat na neplatné heslo.
• Aplikace by měla umožňovat jen N NEplatných pokusů (třeba 20) přihlášení z jedné IP za jednotku času (třeba 20min), jinak v tichosti odkazovat na neplatné heslo.
• Zrobit kontrolu (mini-audit) aplikace, robí-li všechny operace autorizovaně a jak (pevné či variabliní kontrolní klíče/hashe, jejich síla apod.), například fčul tady mám pod rukama jednu bezpečnou php aplikaci, u které si neautorizovaně změním heslo libovolnému uživateli (i nejvyššímu administrátoru aplikace), a jsem z pohledu aplikace jen uživatel (nemám přístup k serveru), jen jsem asi ½ hodiny studoval přes firebug ve FF co se tam děje.
  Toto vidím jako největší bezpečnostní riziko vystavení aplikace napřímo ven (i když přes https)

[Jendа]

případně jejich periodickou změnu

NE!!!

[cz-helper]

Priklanim se k hodnoceni bodu 2 jako ne prilis resici problem bezpecnosti. Co se bodu 4 tyce, je to spise vec zabezpeceni aplikace jako takove, jak bude odolna proti utokum.

Da se tedy bud pouzit HTTPS, kdy je chranen prenos, ale prakticky to neresi ani jeden konec (client-server) od dalsich utoku, nicmene nic se s tim nezkazi (https neni na portu 80 ).

Pripadne reseni pomoci VPN muze zvysit zabezpeceni komunikace, ale jiz bylo zmineno, slaby clanek muze byt pocitac na "druhe strane" (client) a jeho "dalsi" aplikace. Nicmene, ma-li byt alespon nejake zabezpeceni a minimalni pozadavky na doinstalovavani veci, muze se rozchodit napr. i pptp server (zvlada standartni windowsovsky VPN klienty). Dale resit filtrovanim provozu techto spojeni (napriklad takove spojeni umozni jen navazat spojeni na dany server, ne jinam). Vyhoda je takova, ze se muze logovat kdy kdo a odkud se prihlasuje, a v pripade, ze nedo bude mit "moc" pokusu dostat se i jinam, bude zaznam koho ucet je ten "zly"...

Omezeni na konkretni IP (filtrovani) take nic neresi (bylo jiz take zmineno), ne vsichni maji verejnou (a hlavne pevnou) adresu. Viz predchozi odstavec.

Samotne umisteni na virtualni server neresi otazku bezpecnosti. Pokud aplikace ma neco delat, musi davat spravne udaje. Pokud je nebezpeci, ze se nekdo dostane kam nema, je asi problem s aplikaci a je-li pristupna z venku (a nekdo bude mit zajem) stejne budou upraveny data at je to na vlastnim serveru, nebo nekde "mimo sit".

Ulozeni prihlasovacich udaju v php souboru nevidim primarne jako problem. Pokud budou spravne nastavena opravneni na soubory, pripadne (take bylo zmineno) v extra adresari s .htaccess, melo by to stacit. Pokud se k tomu nekdo presto dostane, asi bude problem trochu vetsi .

Osobne bych resil presmerovani portu (idealne kombinace s https - presmerovat oboje a pokud nekdo zada jen http:80 presmerovat ho na https:443). Dale bych nastavil nejake filtrovani napr. max 30 spojeni za minutu z jedne adresy a podobne (iptables). V pripade citlivejsich dat bych pouvazoval o nejake forme VPN - pokud se jedna o "bezne" uzivatele, asi bych zvazil pro toto konkretni reseni pptp server.

[needlinux]

Z uvedenej diskusie mi je jasne, ze nech sa budem snazit akokolvek zabezpecit spristupneny intranet zvonku, zostane zabezpeceny iba proti utokom o ktorych viem. Zostanu tam stale este utoky o ktorych neviem a tych je ako vidim dost - a toto mi citelne vadi.

Idem si to trosku skomplikovat a pokusim sa ist na to takto:

1. Intranet na vnutornej sieti necham z vonku uzavrety.
2. Na ServerHostingu bude spustena jednoduchsia verzia intranetu, kde budu dostupne iba nevyhnutne funkcie pre externych pracovnikov. Pristup na tento pocitat bude z verejnej siete, autorizacia bude menom a heslom. Zabezpeceny bude samozrejme tak dobre ako sa da.
3. Do DMZ zony umiestnim komunikacny server, na ktorom bude vnutorny intranet aktualizovat DB paralelne podla diania vo firme (nie celu DB, iba to co chcem vidiet zvonku).
4. Na komunikacnom serveri bude spustena aplikacia, ktora bude v kratkych casovych intervaloch posielat aktualizovane data na vonkajsi intranet a zaroven odtial stahovat nove data.
5. Vnutorny intranet sa bude tiez v nejakych casovych intervaloch pozerat na komunikacny server, ci tam nieje nieco nove - ak hej, tak si to vlozi do svojej DB.
6. Spristupnit cele uctovnictvo touto formou na urovni editacie a pridavania urcitych zaznamov by bolo dost zlozite z hladiska zachovania integrity dat. Na tento ucel dostane dotycna osoba firemny NB s predinstalovanou VPN a bez administratorskych opravneni.

Toto riesenie mi samozrejme skomplikuje v aplikaciach pristup do DB a vyzaduje to dalsiu pracu navyse, ale myslim ze to bude stat za to. Navyse mi zostane bezat vnutorny a vonkajsi intranet autonomne, takze nemusim riesit dilemu kam vlastne celu aplikaciu umiestnit - vzdy by zostala jedna strana za internetovym pripojenim firmy.

Casovo to bude takto urcite narocnejsie, ale ten NB sa da spachat velmi rychlo a ostatni par tyzdnov vydrzia.

[pht]

No, už tam chybí jen ochrana proti mimozemšťanům ;)

Intranet na vnutornej sieti necham z vonku uzavrety.

Nezapomeňte že tam máte ty VPN.

[petka]

Pokud se uzivatele budou pripojovat jen z jedne IP popr vice tak by se mohlo pomoci seznamu povolenych IP pristupovat na server a to jeste v kombinaci MAC .Jinak existuje dneska 100% ochrana , vzdy je jednou poprve a jak uz tu nekdo psal , zalohovat , zalohovat .

[Jendа]

Pozor, MAC se ztratí za prvním routerem. A my nevíme, jak má postavenou síť – jestli nemá server někde, kde MAC klienta už nebude vidět.