Vlákno názorů k článku Palácový převrat na GameZone.cz od J - Je mi celkem jedno kdo co vlastni, na...
-
J (neregistrovaný)Je mi celkem jedno kdo co vlastni, na GZ sem hral jen parkrat, spis jen test. Ale at uz se delo cokoli, zprovoznit alespon primitivni html stranku s textovou informaci typu "je to v haji, vydrzte ..." umi i male decko, ktere srv vzivote nevidelo a dela to poprve podle navodu.
Totez plati samozrejme o zprovozneni hernich serveru, i kdyby to melo byt stylem zverejneni IP adres a portu, je to otazka nekolika hodin maximalne.
To co se stalo (a jeste stale deje) je dokonalym prikladem neschopnosti.
Co se nadavek a pospinovani tyce, z toho co vim, jde predevsim o hrace, nikoli o vedeni byvale GZ. V teto souvislosti je jednoznacne onen clanek obvinujici je z ddos na zalobu, ovsem ne ze strany PG, ale byvale GZ.
BTW: Omezit pristup na srv na IP v CR nebo alespon s reverzem .cz je otazkou nekolika minut. -
8an (neregistrovaný)Já mám pocit že se nemají z čeho navzájem obviňovat, neschopnost je rozdělena rovným dílem...
Otevřený Remote Desktop na www.gamepark.cz opravdu není ukázka profesionality.
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
53/tcp open domain
80/tcp open http
1025/tcp open NFS-or-IIS
1234/tcp open hotline
3389/tcp open ms-term-serv
8021/tcp open ftp-proxy -
neznamy pisatel (neregistrovaný)Myslim, že v tomdle byl zase byznys, potřebovali rychle a nejjednodušší cestou zprovoznit server, tudíž šla profesionalita mnohdy stranou. Protože platilo, čim dřív tim líp (rozuměj čim dřív, tim víc hráčů => tim víc peněz) Myslim, že to v budoucnu celý z profesionalizujou, ale teď maj spousty starostí s něčim jinym. V jednoduchosti je síla.
-
Libor Vanek (neregistrovaný)No, to nevim, ktere kruhy povazujes za hodne sveho jmena... Uz z principu by mely byt otevrene jen ty porty, ktere jsou bezpodminecne k provozu potreba. A to RD urcite neni (ten slouzi na vzdalenou spravu) - ten by mel byt otevreny bud jen pro urcitou IP nebo (nejlepe) by mel byt vzdaleny managment takovehoto duleziteho serveru resen jinak (remote KVM - uz jen kvuli vzdalenemu resetu v pripade totalniho zatuhu).
-
Aneb vyjmenujte mi 10 linuxovych serveru, jejichz sprava je outsourcovana a nemaji otevrene (byt jen z casti Internetu) port 22.... Teoreticke dychansky s praktickym zabezpecenim systemu moc dohromady nejdou... teoreticky jde vsechno, vcetne kvantovych pocitaci, tak proc vlastne delat jakekoli kroky ke skryvani informaci...:-) -
Libor Vanek (neregistrovaný)Srovnavas nesrovnatelne. SSH proslo spoustou bezpecnostnich auditu, kod je k dispozici a stabilni uz vice nez 10 let (AFAIK). MS implementaci neauditovala zadna nezavisla bezpecnostni autorita, MS je prosluly spoustou bezpecnostnich problemu a spatnym designem programu (z bezpecnostniho hlediska). Oproti tomu SSH pochazi z BSD rodiny (IIRC), kde je kladen extremni duraz na kvalitu kodu.
-
A presto vsechno tvori jen lide... takze abychom se vratili k prokazatelnym skutecnostem a nikoli dojmum a slepe vire. SSH nikoli jako protokol (i kdyz verze 1 se dnes povazuje za doslova nebezpecnou, ale z jinych duvodu), ale OpenSSH implementace mela dost kritickych bezpecnostnich problemu behem sve historie. Posledni, mne znamy, problem byl nalezen pri auditu kodu loni, pravda, situace to byla pomerne specificka (treba mne by neohrozila), ale na druhou stranu, pokud se okolnosti vyskytly, tak z toho byl remote uspesny utok = do systemu vrata. Srovnam-li to s RDP, tak tomu bych vytkl vsechno z opacne strany - puvodni verze protokolu ma prokazatelnou a prokazanou kryptologickou slabinu, kterou vsak v praxi nikdo nebyl schopen vyuzit (teorie je krasna, o praktickem vy/zneuziti nevim). Na stranu druhou novejsi verze prokotolu jiz temito neduhy netrpi - resp. ani kryptologicke autority nemaji po strance designu vyhrady - muzete oponovat? - a pokud nezanedbame otazky socialniho inzenyrstvi apod., tak mame v podstate bezpecnostni hradbu, ktera za svuj zivot prokazala, ze je to opravdu hradba - ja v teto pozici neznam podobne implementacni problemy, ktere se resily v OpenSSH, cimz nerikam, ze nexistovaly, jen mi nejsou znamy.
Tak a ted mi reknete, zda-li stale lpite na svem puvodnim tvrzeni o (auto)bezpecnosti...
-
Libor Vanek (neregistrovaný)Ano, trvam. Uz jen z toho duvodu, ze k RDP nejsou k dispozici volne zdrojove kody (i kdyz verim, ze zli hosi se k nim dostanou).
Jak rikam (a jak rikas i ty) - SSH ma za sebou hromadu auditu (od toho jsou audity, aby se nasly chyby), RDP ma pouze (jak rikas ty) audit NAVRHU PROTOKOLU! SSH ma urcite taky design protokolu "dokonaly", chyby jsou v implementaci. A ted si predstav, kolik chyb v implementaci SSH bylo za tu dobu nalezeno a to ten kod urcite videlo mnohonasobne radove vic lidi nez RDP - kolik chyb muze v RDP byt...
Za dobu, co aktivne Linux vyuzivam (7 let) nevim o zadnem remote-exploitu pro SSH (alespon pro defaultni Red Hat instalaci se standarne nastavenym SSH). -
RDP ale taky, ze o tom MY nevime jeste neznamena, ze nejsou... Mimochodem pristup k temto source ma daleko vetsi okruh zajemcu nez si vetsina lidi mysli... bezpecnostni slozky statu netvori jen pitomci... A k tomu Linuxu - nerad bych se mylil v case, ale OpenSSH 1.2.25 a vyse neni tak stare, jak uvadis a na to remote-exploit fakt existoval... (a nebyl jediny). A exploit nebyl jen na OpenSSH...
-
anonymní"auto" bezpečnost bude právě tím problémem o kterém mluvíte
1. s prominutím a nemyšleno urážlivě může pro ssh přístup povolit root účet jenom prase! (přiznávám jsem také prase pokud by se nejednalo o stroj zákazníka), tzn. login pouze pro uživatele který nemá žádná práva (ano musí být ve skupině wheell, které ovšem zakážeme vše až na su atp.). Tím se zabrání zneužití chyby, kterou jste měl na mysli (nenapadá mě za posledních několik let žádná, která by odpovídala Vašemu příspěvku mimo "odposlechnutí hesla" pří "inicializaci spojení")
2. pokud se jedná o komerční stroj (někdo Vám platí za správu atp.), tak přístup k ssh pouze z povolených IP!!! OK a co tedy dělat když musím řešit problém a jsem daleko od stroje, ze kterého je povoleno spojení? Jste snad sysop, tak máte nějaký vlastní (non-mission critical) stroj s veřejnou IP, ze které je přístup povolen, tak se na něj lognete a z něj pak stroj s problémem.
PS.: prosím o nepostování reakcí na případné gramatické chyby, jedná se o svobodnou diskuzi na internetu (nemusíte ji číst) a podívejte se na čas odeslání!
PS.: případná omluva za nesmysly v příspěvku - jsem pouze newbie -
Ondřej Čečák (neregistrovaný)"s prominutím a nemyšleno urážlivě může pro ssh přístup povolit root účet jenom prase!"
"PS.: případná omluva za nesmysly v příspěvku - jsem pouze newbie"
Nejak mi unika, proc se oznacujete za newbie a jeste pouzivate takova silna slova.
Jaky mas smysl zakazani loginu na roota? Jediny o kterem vim ja je nutnost zvyseni prav treba pres su, coz se da trochu logovat. -
Ad 1 - cim zvysujete bezpecnost? Bavili jsme se nikoli o zabezpeceni systemu a izolaci uzivatelu, ale o remote bezpecnosti - tam zadny rozdil mezi prihlasovanim primo na roota a prihlasovani na nejakeho uzivatele a pak povysovani prav neni.
Ad 2 - jednak je Vami nastinene reseni krajne nevhodne - staci vypadek stroje (duvodu Vam napocitam milion), o kterem mluvite, a muzete si sbalit 5 svestek a vyrazit na misto... - to zvlastne pri umisteni serveru geograficky po Zemi je opravdu dobra konstelace, zejmena za predpokladu smluvne podchycene doby reakce... Druhak - i kdyby byl pristup na stroj omezen na konkretni oblasti, tak to jde udelat nekolikero zpusobem a bezpecnosti nijak neublizi (ani ji nesnizi!), pokud se pro testovaci nastroje jako NMAP ten port tvari, ze je ve stavu "open" - jednak to o skutecnem stavu nic nerika, jednak to nemusi byt pravda...
-
J (neregistrovaný)No nevim jak vy, ale ja bych rek, ze na web serveru by mel byt dostupny jen port 80, maximalne jeste 443. Ftp je uz ke zvazeni, ale budiz, spis bych jej omezil na vybrane IP. Ostatni tam nema co delat.
Nejak me treba nenapada duvod, proc na web serveru provozovat DNS, smtp a pop/imap.
ČLÁNKY DO MAILU