abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 0
včera 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 16
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 2
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 767 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Zabezpecenie intranetu (Apache + PHP + MySQL)

6.1.2010 11:09 needlinux | skóre: 2
Zabezpecenie intranetu (Apache + PHP + MySQL)
Přečteno: 1369×
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.

Řešení dotazu:


Odpovědi

6.1.2010 11:38 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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).
6.1.2010 12:33 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
6.1.2010 12:44 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
6.1.2010 13:13 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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...
6.1.2010 13:26 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
In Ada the typical infinite loop would normally be terminated by detonation.
6.1.2010 13:49 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
6.1.2010 15:08 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
6.1.2010 15:26 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
Dakujem za vycerpavajuce informacie
6.1.2010 15:48 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.

In Ada the typical infinite loop would normally be terminated by detonation.
6.1.2010 15:59 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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?
6.1.2010 16:31 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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ý).
In Ada the typical infinite loop would normally be terminated by detonation.
6.1.2010 16:18 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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 :)
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
6.1.2010 16:39 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
In Ada the typical infinite loop would normally be terminated by detonation.
6.1.2010 19:03 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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á.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
6.1.2010 20:19 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)

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

In Ada the typical infinite loop would normally be terminated by detonation.
H0ax avatar 6.1.2010 17:13 H0ax | skóre: 36 | blog: Odnikud_nikam
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
LinuxWay | blog |  LiCo
6.1.2010 17:33 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
Jak s tím souvisí objem?
In Ada the typical infinite loop would normally be terminated by detonation.
H0ax avatar 6.1.2010 17:51 H0ax | skóre: 36 | blog: Odnikud_nikam
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
LinuxWay | blog |  LiCo
6.1.2010 18:50 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
In Ada the typical infinite loop would normally be terminated by detonation.
Dalibor Smolík avatar 7.1.2010 11:38 Dalibor Smolík | skóre: 54 | blog: Postrehy_ze_zivota | 50°5'31.93"N,14°19'35.51"E
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
Když někdo exploitne účetnictví a udělá tam bordel, nebo projektová data
Zálohovat, zálohovat .. :-)
Rozdíly v řeči a ve zvyklostech neznamenají vůbec nic, budeme-li mít stejné cíle a otevřená srdce.
7.1.2010 13:45 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
Záloha proti ukradeným datům prodaným konkurenci nebo firemním penězům na cizím účtě moc nepomůže :)
In Ada the typical infinite loop would normally be terminated by detonation.
6.1.2010 15:52 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
In Ada the typical infinite loop would normally be terminated by detonation.
Jendа avatar 6.1.2010 21:20 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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).
6.1.2010 21:38 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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а avatar 6.1.2010 21:56 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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…
6.1.2010 22:38 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
6.1.2010 12:12 Vantomas | skóre: 24 | Praha
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)

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.

6.1.2010 12:51 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
9.1.2010 23:54 Vantomas | skóre: 24 | Praha
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)

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

6.1.2010 13:19 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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ě.
In Ada the typical infinite loop would normally be terminated by detonation.
6.1.2010 14:14 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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?
6.1.2010 15:59 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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?
In Ada the typical infinite loop would normally be terminated by detonation.
6.1.2010 16:12 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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
6.1.2010 16:53 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
In Ada the typical infinite loop would normally be terminated by detonation.
6.1.2010 17:00 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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
6.1.2010 17:07 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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ě.
In Ada the typical infinite loop would normally be terminated by detonation.
6.1.2010 17:24 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
6.1.2010 17:44 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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íť.

In Ada the typical infinite loop would normally be terminated by detonation.
Dalibor Smolík avatar 6.1.2010 13:19 Dalibor Smolík | skóre: 54 | blog: Postrehy_ze_zivota | 50°5'31.93"N,14°19'35.51"E
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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íť.
Rozdíly v řeči a ve zvyklostech neznamenají vůbec nic, budeme-li mít stejné cíle a otevřená srdce.
6.1.2010 14:52 NN
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
HTTPS+ omezeni IP + omezeni portu, nebo VPN + omezeni portu..

NN
6.1.2010 16:06 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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)
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
Jendа avatar 6.1.2010 21:18 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
případně jejich periodickou změnu
NE!!!
6.1.2010 20:23 cz-helper | skóre: 5
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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 :-D.

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.
Řešení 1× (needlinux (tazatel))
7.1.2010 09:14 needlinux | skóre: 2
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
7.1.2010 10:30 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.
In Ada the typical infinite loop would normally be terminated by detonation.
petka avatar 9.1.2010 20:06 petka | skóre: 25 | blog: heydax | Klasterec N/O
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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 .
Ubuntu server - Asus E35M1​-M ​- AMD Hudson M1 , 2x Technisat Skystar2 , 2x 1GB Lan , WiFi mod AP ,vdr,mysql,apache2...
Jendа avatar 10.1.2010 00:22 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Zabezpecenie intranetu (Apache + PHP + MySQL)
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.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.