Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Mirek Prýmek

Stran: 1 ... 582 583 [584] 585 586 ... 618
8746
Odkladiště / Re:IT security manager požadavky
« kdy: 02. 01. 2012, 07:52:48 »
teraz si davam za jar toto http://is.muni.cz/predmet/1431/M0170

Jo, kryptografie s Pasekou byla paseka :) Nerad na to vzpomínám, silně jsem to podcenil přesto, že jsem to potřeboval udělat - na přednášce jsem byl tak třikrát... Zachránil mě jenom ten jeho systém "já od zkoušky nevyhazuju, budete tady sedět tak dlouho, dokud sami neuznáte, že na to nemáte". Tvrdošíjně jsem to asi dvě hodiny odmítal uznat ;)

8747
Odkladiště / Re:IT security manager požadavky
« kdy: 28. 12. 2011, 09:16:03 »
Čteš Bezpečnostní střípky, které tady na Rootu vychází? Pokud je budeš číst včetně všech odkazů, myslím, že rychle zjistíš, o čem vlastně ta bezpečnost v praxi je...

Jinak pokud ti jde skutečně o management, tak si myslím, že je to víc o znalosti metodik (ne jen bezpečnostních, ale i projektového řízení apod.) než o jednotlivých technologiích. Zkus si třeba pro začátek něco málo přečíst o ITIL, Six Sigma apod. - možná zjistíš, že by tě to nebavilo a raději bys než manažera dělal bezpečnostního specialistu.

8748
Studium a uplatnění / Re: FIT VUT vs. FI MUNI
« kdy: 28. 12. 2011, 09:11:04 »
No vidim, že už je to t uchvíli mrtvé, ale snad se na to ještě někdo kukne. Mám dotaz, jak zjistim, které termíny NSZ uznává VUT FIT? Vím, že jsem to kdysi viděl, ale teď to nějak nemohu najít (myslím NSZ z Matematiky). Abych náhodou nešel na nějaké zkoušky, které oni pak nebudou zohledňovat :)

A není lepší tuhle otázku poslat mailem škole, než se ptát na fóru?

8749
Distribuce / Re:Poraďte distro na práci
« kdy: 27. 12. 2011, 10:05:35 »
ja by som na mac presiel hned ale nemam na to prachy

Pres Ebay (DE,US) se daji pouzite macy kupovat za rozumne ceny.

8750
Sítě / Re:Jednosměrné vs obousměrné pravidlo v iptables
« kdy: 22. 12. 2011, 11:10:16 »
ale někde v pravidlech musí být uvedeno i pravidlo se zmiňovaným --state ESTABLISHED,RELATED

Ještě možná malou poznámku: tohle pravidlo je dobrý dát ne "někam", ale pokud možno na začátek, aby se snížil počet pravidel, kterýma musí každý paket procházet.

8751
Sítě / Re:Jednosměrné vs obousměrné pravidlo v iptables
« kdy: 22. 12. 2011, 11:05:08 »
Ano, však tak jsem to myslel. Píšou se pouze pro první paket daného spojení (kdo spojení navazuje), ale někde v pravidlech musí být uvedeno i pravidlo se zmiňovaným --state ESTABLISHED,RELATED, jinak tento princip definování pouze prvního paketu nebude fungovat, jelikož nebude firewall nakonfigurován jako stavový. Pokud bychom toto pravidlo s --state ESTABLISHED,RELATED neuvedli, tak to nebude fungovat... Nebo ne?

Jo.

Ale jinak se samozřejmě stavový firewall dá používat i jako nestavový - pak je potřeba ty pravidla napsat jinak.

8752
Sítě / Re:Jednosměrné vs obousměrné pravidlo v iptables
« kdy: 22. 12. 2011, 10:38:44 »
Aha, takže pokud je firewall nakonfigurován jako stavový (má na začátku hromadné pravidlo s --state ESTABLISHED), tak se jednotlivými pravidly již pouze definuje, kdo (+ další parametry) může a nemůže navazovat spojení. Opačný směr se poté povolí automaticky. Pokud ovšem toto pravidlo chybí, tak se jedná o bezestavový a je nutné pro každé TCP spojení povolit směr tam i ven, pak ovšem nemáme kontrolu nad tím, kdo spojení navázal. Tudíž to může být nebezpečné.

Chápu to správně?

Myslím, že ne. Jak už říkali předřečníci, obvykle se to dělá tak, že se pravidla píšou jenom pro PRVNÍ paket daného spojení a všechny další už spadnou do established/related. Kontrolu nad tím, kdo spojení navázal, pochopitelně máme, protože ten první paket jde nějakým směrem...

Taky bych ještě dodal, že "related" znamená, že paket se nějakého existujícího spojení týká, ale není přímo jeho součástí (nejrůznější ICMP apod. nebo dokonce i FTP datové spojení)

8753
V obecné situaci je možné třeba nepřipojit k síti klientskou stanici, která nemá všechny patche OS a nainstalovaný antivirus a přihlašují se do windowsové domény. Ale to už je o něčem jiném.

Ano. Vzhledem k tomu, že řeč byla celou dobu o autentizaci vůči webové aplikaci, je tohle trochu o něčem jiném.

8754
Asi je zbytečné se bavit o bezpečnosti s lidmi, kteří nejsou schopni rozlišit bezpečnost věcí, které mám plně pod svou kontrolou (soubor s hesly) od věcí, které pod svojí plnou kontrolou nemám (komunikační trasu, bezpečnost vydavatele certifikátů).

Ale jo, to samozřejmě rozlišuju a klidně se o tom můžeme bavit.

Můj názor ja takovýhle: průměrnou úroveň zabezpečení serveru s hesly u kdejakého hostingu, webu, i registrátora odhaduju na řádově nižší než zabezpečení typické certifikační autority.

Ovšem jestli se někdo cítí na to (a má k tomu potřebné prostředky), že na svých serverech dosáhne vyšší úrovně bezpečnosti, než mají CAs, tak v tom případě je samozřejmě lepší, když na ně spoléhat nebude.

Ovšem ta úvaha má drobnou chybku: i kdybych se rozkrájel, nemám pod svou kontrolou klientské stroje... což tu úvahu trochu degraduje, ne?

8755
Jo, stejně tak jako máme k dispozici certifikační autority, bezpečnost jejichž certifikátů byla narušena.

Zatímco bezpečnost databáze plaintextových hesel nebyla nerušena nikdy...

8756
A nestačilo by rovnou na začátku říct "hashované heslo je bezpečnější, pokud mám k dispozici zabezpečený kanál"?

Https je standard. Bral jsem jako samozřejmost, že ho máme k dispozici.

Stejně tak jsem bral jako samozřejmost, že máme počítač, a nezmínil jsem se o tom.

8757
Ok, v tom případě je hashované heslo patrně bezpečnější.

Nestačilo rovnou na začátku říct "plaintext heslo je bezpečnější, pokud jediné, co mám k dispozici, je nebezpečný komunikační kanál a nechci nad ním stavět kanál bezpečný"?

To bysme pak asi byli všichni hned doma.

8758
Tento přístup ke kryptografii ovšem dost znesnadňuje kryptoanalýzu komplexnějších systémů. Řekneš "mám zabezpečený kanál". Kryptoanalytik se zeptá - co se stane, když bude tento kanál narušen? Musím si heslo změnit? Tato odpověď se liší podle způsobu autentizace.

Dobře. Netrvám na tom, že tomu musíme říkat zabezpečený kanál. Můžeme tomu tedy říkat "bezpečný způsob prokázání znalosti".

8759
Jsou situace, kdy nepotřebujete zabezpečený kanál

Ano. A jsou i situace, kdy neexistuje na světě jiná osoba než já. V takovém případě je "nejbezpečnější" si heslo nalepit na monitor.

Předpokládám ale, že normální admin, který dělá dobře svou práci se zeptá: "Jak nejlíp systém zabezpečím?" A odpoví si: "Pomocí https a hashovaných hesel". Všechno ostatní je zbytečná chytristika.

8760
No nic, přestává mě to bavit, takže se omezím na konstatování, že https+hash je za běžných okolností bezpečnější než http+c_r+plaintext.

V tom se shodneme.

Tímpádem je kauza skončena, protože jelikož https používají všichni, plaintext hesla prostě bezpečnější NEJSOU.

Toto bohužel nechápu. V challenge response se přece žádné tajemství nikam neposílá.

To je slovíčkaření.

Jestliže posílám text X, zašifrovaný klíčem Y, posílám tím klíč Y nebo ne?

Důležité je, že informaci "znám Y" prokážu tak, že mi Y nikdo při tom nemůže po cestě ukrást. To je V PODSTATĚ "zabezpečený kanál".

Jestli tomu tak ale říkat nechceš, tak neříkej, mně kvůli tomu prsa nenarostou :)

Stran: 1 ... 582 583 [584] 585 586 ... 618