Hup.hu HTTPS-en

Közösségi kerekasztal

biztos volt már róla szó, de miért nincs? :O

  • 6676 megtekintés

az oldalon lehet regisztrálni.

regisztrálás után belépni -> fórumon hozzászólni.

belépve lenni.

mind eközben a hozzáférést a kliens <-> server közt ellopni -> nagyobb támadási lehetőség a hup.hu ellen

annyival növelné a terhelést a https?:O

logikus magyarázat ez ellen létezik?:O

> nem a hozzászólásomat, a "hozzáférésemet". felhasználónév/jelszó páros

Ezt részletezd légy oly kedves. Kezdjük az első HTTP session felépítésénél. Mit küld a böngésződ, és mit kap válaszul a szervertől?

>> A "nagyobb" az mondjuk 10 helyett 11? Vagy mi?
> pontosan

Ezt részletezd légy oly kedves. Hogy jött ki neked a "10", illetve "11" támadási lehetőség?

> Ezt részletezd légy oly kedves. Kezdjük az első HTTP session felépítésénél. Mit küld a böngésződ, és mit kap válaszul a szervertől?
tényleg nem vágod, h. mi a különbség abban, h. le lehet lesni a jelszót, v. nem? flame-nek ez vérgyenge - közösségi kerekasztalban indítottam a topicot, mert választ keresek.

> Ezt részletezd légy oly kedves. Hogy jött ki neked a "10", illetve "11" támadási lehetőség?
ha azt állítod, h. [valószínűség szerint] nehezebb egy bejelentkezett felhasználóval bejutni a serverre, mint egy nem-bejelentkezettel, akkor értelmetlen a beszélgetés

> tényleg nem vágod, h. mi a különbség abban, h. le lehet lesni a jelszót, v. nem?

Van egy spéci kendőm, amikor jelszót gépelek, akkor (azon kívül hogy halkan, random szüneteket tartva nyomogatom a gombokat) ez van a kezemre terítve, hogy ne lehessen lelesni a HUP-on használt jelszavamat.

- van aki kavezobol netezik
- van aki munkahelyen
- van aki a szomszed wifijen csucsul
- van aki a tarsashaz kozos vegpontjarol jar ide

mindegyik helyzet olyan, ahol nem kozvetlenul a dsl modembe vagy dugva, hanem koztes dobozon kersztul ered el a vilaghalot. nem mindig tudod, hogy ki az aki hozzafer a router/proxy/gateway gephez.

sbalazs.

a szal ugy kezdodott, hogy 'Minek?' <- ami pedig a https-re vonatkozott. te erre feltettel par kerdest, amikre megprobaltam valaszolni. te ezekbol azt szurted le, hogy bizonyara one-time jelszo azonositast szeretnek. kijavitottam a megallapitasod.

most pontositanek a fentieken: amikor azt irtam, hogy https-t szeretnek, azt ugy ertettem, hogy a korabbi hozzaszolasaimmal ezen protokol elonyeirol beszeltem, nem pedig az altalad emlitett azonositasi eljarasrol.
nem kardoskodom sem mellette, sem ellene. egyszeruen azt hittem, hogy azert tettel kerdojelet a mondatod vegere, mert valaszt varsz es nem azert mert unalmas az esti tevemusor es kedved tamadt szorszalakat hasogatni egy forumon.

tovabbi szep estet,
sbalazs.

Szerintem te meg tudatlanul, hozzá nem értően kötekedsz, mindezt olyan stílusban, mintha legalábbis te szartad volna a spanyolviaszt. Vegyél vissza egy kicsit, és nem pofázz bele olyan dolgokba, amikhez rohadtul nem értesz.

---
http://xkcd.com/258/

Apple MacBook Pro 13"
C2D 2.26GHz/3MB | 4GB@1067MHz | 160GB@5400rpm SATAII

Alázz meg egy szakmai hozzászólással.

Pld írhattad volna, hogy a "nincs" helyett a "csak rövid ideig van" is elegendő lehet, ami a one-time-password megoldások felé vezet.

Vagy megkérdezhetted volna, hogy mikor nincs "felhasználónév/jelszó"; én meg megírtam volna, hogy tanúsítvánnyal történő bejelentkezésnél.

Vagy valami ilyesmi. A szimpla dühöngés helyett.

Ha a számítógéped alá tud iratni bármit, akkor ha felnyomják a gépedet, akkor a felnyomást végző rosszfiúk is bármit alá tudnak iratni. Legalább addig, ameddig nem veszed észre és húzod ki a kártyát. A PIN pedig nem véd, mert azt a gépeden írod be.

Az már igaz, hogy nem ugyanaz a kaliber. De a biztonság illúziójába sohasem szabad ringatnunk magunkat.

Ami utána az esetel 99%-ában titkosítatlanul kering a világban.

Olyan ez, mintha valaki arra verné magát, hogy IRC-n SSL-l megy egy szerverre, aztán egy channelbe beírja, hogy ő mekkora secure, mert SSL. Jó, és a többiek? Vagy ha nagyobb szerver, az egyes node-k között?

----------------
Lvl86 Troll

Az SSL-en történő IRC-zésnek azért az az előnye megvan, hogy a NickServ jelszód nem plain txt megy. Meg ha jól emlékszem a szerver jelszó sem...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

hátha nem akarom, hogy valaki, aki a wifimen lóg, lássa, hogy én trollkodok gabucino néven a hupon. (Persze nem)

De egyébként pl. én nem szeretem, ha mások feltétlenül látják, hogy mit olvasok. Azt feltételezem (bár nem értek ehhez ennyire), hogy https felett csak annyit látnak, hogy a hup.hu géphez kapcsolódtam, de azt nem, hogy melyik cikket olvasom, melyik fórumba mit írok be.

Eszembe jutott egy példa (ha rossz, úgyis szóltok): munkahelyről netezek, tele van a tököm az egésszel, állást keresek a hup fórumban. De nem akarom bent közhírré tenni, hogy le akarok lépni.

( Dwokfur v | 2011. 02. 25., p – 20:03 )

+1

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( nrgie | 2011. 02. 25., p – 20:34 )

Én meg néha reflexből keresem a like gombot itt. :)

( trey | 2011. 02. 25., p – 21:15 )

Mennyi newbie. Annak idején a HUP ment https-en (is).

--
trey @ gépház

Mit jelent pontosan a normálisan meg van csinálva?

Én üzemeltetek (haveroknak) webszervert, ott a https-hez kellett egy picit konfigurálni meg a startssl-nél aláíratni a tanúsítványt.

Pénzben jelentkező költsége 0 volt. Időráfordítás kb két óra. A gépet nem kellett emiatt megváltoztatni (nincs akkora terhelés, nem kellett új IP cím).

Persze nem hasonlítható össze egy napi pár tíz látogatós oldal egy huppal, de kíváncsi vagyok, mit kellene neked máshogy csinálni, mivel jár, és persze mi az, ami ezekből pénzbe kerül.

( Arbiter | 2011. 02. 26., szo – 12:15 )

És igazából ennek milyen gyakorlati haszna lenne?

Attól tartunk, hogy pl. Sting egyik éjjel, miután megnézte a Mission Impossible első részét, a plafonról leereszkedik a szerverszobába, ráakaszt valami Windowsos lehallgató kütyüt a HUP-os szerver patch kábelére, kideríti az admin accountok jelszavait, és meghekkeli a Drupalt (bár ezt a részt inkább ki fogja szervezni, elég a saját CMS-ét érteni), hogy ezentúl csak prog.hu-s hírek jelenjenek meg rajta?

Vannak-e itt annyira értékes adatok, illetve keletkezhet-e az adatlopásból akkora kár, hogy megérje SSL-en keresztül (is) szolgáltatni? Szerintem nem.

Ennél sokkal érdekesebb, hogy a begyűjtött jelszavak (pl open wifi-n) mennyi más szolgáltatásnál is érvényesek. Tudom-tudom most majd beirja a sok okos, hogy ők minden egyes webes regjükhöz másik jelszót használnak, de a valóság nagyon más.

Terhelés ügyében egyszerű a dolog, külön login page kell és csak azt kell védeni, nem kell az oldal teljes forgalmát ssl-ezni.

Én az oldalakat is titkosítanám.

Volt a múltkor egy műsor a TV-ben, a stáb lehallgatott egy wifi kapcsolatot, aztán becsengettek a házba, és mondták az embernek, hogy tudják, hogy most vett repülőjegyet ide és ide, stb. És ha nem teszi védettebbé a wifijét, akkor lehet, hogy legközelebb amikor nyaralni megy, a betörők fogják tudni, hogy mikor nincs otthon.

Nekem sok fontos oldalon külön-külön pwgennel generált jelszavam van, de van számos nem fontos oldal, ahol valóban egy jelszó van mindenhol. Persze ezekért nem is kár igazán, de azért nem mondanám el boldog boldogtalannak.

Ezeken az oldalakon pl. OpenID-t szívesen használnék, és akkor mehet titkosítatlanul is akár az autentikáció.

Én nem látom sok értelmét a teljes oldal titkositásának, de persze, ha a hw birja, akkor miért ne. De ha nem birja, akkor jöhet, hogy csak a login van titkositva, azt gondolom elbirja.

A repülőjegy vásárlást azért nehezen lehetne idekeverni, ez egy - a PM-eken kivül - nyilvános oldal, aki ide leir olyan infot, hogy mikor nem lesz otthon és az is kiderül, hogy hol lakik vagy egyéb érzékeny info-t annak tökmindegy, mert az ssl bevezetése után is bárki elolvashatja ugyanezt az info-t. Itt az egyetlen érzékeny adat a jelszó és talán a PM.

jo hogy leirtad, mar en is akartam.
ha valaki megnyomna a hup-ot, es megszerezne az itteni adatokat (jelszavak, privat uzenetek, ki melyik ip-rol lepett be melyik userhez), akkor lenne hirtelen kapkodas, hogy hoppa, ugyanazt a jelszot hasznalom itt, mint az itt megadott email fiokomhoz, hopp, itt verettem pm-ben masik sracnak, hogy mennyi adatot vittem haza elozo munkahelyrol, etc.

szoval egesszen addig lehet bagatelizalni a biztonsag kerdeset, amig valaki ra nem szan nehany orat/napot, es be nem nyomja az oldalt.
en itt jottem ra, hogy a hup.hu-n olyan jelszot szabad csak hasznalni, amit sehol mashol nem hasznalok semmire.

Tyrael

Nem is kell semmilyen ilyen jellegű adatot megadni. Elég ha felnyomják az oldalt.. Kíváncsi lennék ki használja ugyanazt a jelszót több helyre, netán mindenhova. Legalábbis nekem nincs kedvem 10+ karakteres jelszavakat megjegyezni.. Kettőt tudok aztán ennyi, ezeket használom különböző helyeken. A váltogatás azért néha megtörténik. Nincs szabályos időköz..

Tehát elég ha felnyomják az oldalt, megszerzik a jelszavakat és nagy eséllyel bejutnak az ember e-mail fiókjába meg még kitudja hova..

Tyra3l-től indult a dolog, ő inkább céges adatokat emlegetett.. ("itt verettem pm-ben masik sracnak, hogy mennyi adatot vittem haza elozo munkahelyrol, etc.") Amit nem éppen túl jó ötlet se se privát üzenetekben se sehol máshol megadni. Tehát olyan dolgokat, amiket nem kötelező magadni.

Tehát erre jött az, hogy ezeknek a megadása fail.. :-)

Gyerekek, most komolyan. SMTP-n szenzitív adatokat? PM-ben egy weboldalon keresztül? Ki a rák tudja garantálni, hogy ezt az oldalt senki, soha nem nyomja fel? Vagy nyomta már fel? Senki. Erre kell felkészülni. Mondjuk azon, hogy valaki plain text-ben levelez a HUP-on keresztül, nem fog segíteni az, hogy az oldal SSL-t használ vagy sem...

--
trey @ gépház

- trey azt írta "itt", az a hup rendszer a jelen körlmények közt, teljesen egyértelműen, ráadásul aztóta igencsak megerősítette ezt szóval nem értem mit nem értesz

- a másik ami fontos egy fórumon: a logika, azaz nem kell a másikat fárasztani olyan ellentmondással hogy szerinted jó lenne plusz biztonság közben meg jó hogy nem a jelszavadat írod le hozzászólásban

"Nem is kell semmilyen ilyen jellegű adatot megadni" - Akkor én fogalmaztam rosszul. A "megadás" alatt én adatkiadást értettem, ami nem a felhasználó azonosítására szolgál és szerintem mindenki más is. Úgy látszik tévedtem.
A jelszó beírása is valamilyen formában megadás, csak az elkerülhetetlen és ha titkosítod, akkor senki nem látja.
Tehát ezt is megadod, de nem úgy, ahogy más adatokat.
A jelszót meg kell adni, de csak a rendszernek.. Ez olyan adat, amit muszáj megadni, ellenben céges adatokat pm-ben kiadni emberi butaság...

igen, arra probaltam celozni, hogy a latogatok egy (az atlaghoz kepest talan nagyobb) resze tisztaban van az IT biztonsag idevonatkozo passzusaival, ennek ellenere biztos vagyok benne, hogy lehetne nagyon mokas dolgokat talalni, es meg a nagyhangu, magukat biztonsagban erzo emberek accountja korul is.
szemely szerint en ugy gondolom, hogy bar egy kocsma ruhataratol sem varom el, hogy a svajci bankokhoz hasonloan vedje a ra bizott ertekeket, de azert ne egy nyitott ablaknal levo fogasra legyenek felakasztva a kabatok, amit az ablakon benyulva barki elvihet.
egy ssl cert beuzemelese gyakorlatilag elenyeszo penz/energiabefektetest igenyelne, es mar egy kicsit jobban aludnank ejszaka.

szerintem

Tyrael

Hogy az oldal HTTPS-t használ, nem garancia arra, hogy nem törik meg az oldalt. Remélem ez azért tiszta. Bármelyik oldalt bármikor megtörhetnek. A HUP-nál sokkal nagyobb, sokkal nagyobb stábbal, sokkal nagyobb költségvetéssel, sokkal nagyobb és jobb szakembergárdával rendelkező oldalakat is megtörtek már. Tehát arra kell felkészülni, hogy itt az adatok nincsenek biztonságban. Ebből kifolyólag ide nem adunk meg szenzitív adatot.

--
trey @ gépház

igen, eppen ezert szamit manapsag az is alapnak, hogy nem taroljuk szerver oldalon plainben a jelszavakat, es sorolhatnam.
mert tudjuk, hogy nincs 100%osan biztonsagos rendszer, ezert nemcsak a behatolaselharitason dolgozunk, hanem a potencialisan okozhato kar minimalizalasan.

pl. mod_security sem veletlenul volt(van?) az oldalon.
szoval azt gondolom, hogy azert amit meg lehet tenni a biztonsag erdekeben, azt nem kellene ilyen ervekkel lesoporni az asztalrol.

Tyrael

Ne haragudj, de hadd kérdezzem már meg, hogy hol söpörtem le bármit is az asztalról? Egyelőre senki sem vetett el semmit. Annyit mondtam, hogy egy internetre kötött gép sosem életbiztosítás és SSL ide vagy oda, nem kell ide megadni éles e-mail címet (jó a freemail is csak éljen), nem kell ide megadni jelszónak a bankkártya PIN-t (senki se kéri, teljesen jó egy apg-vel generált random jelszó). Ha ez be van tartva, akkor semmilyen számodra értékes dologhoz nem lehet az oldalon keresztül hozzájutni. Azt hittem, hogy ezek széles körben ismert dolgok...

--
trey @ gépház

Nem bagatelizálom, hanem reálisan gondolkodom. Nyilvánvalóan nem tudom garantálni 100%-ban (ki tudja?), hogy sosem férnek hozzá az adatokhoz. A legjobb szándékom ellenére sem. A legjobb amit ajánlhatok, hogy senki sem bízza szenzitív adatait az oldalra.

Egyébként, csak neked, még egyszer: Volt már SSL a HUP-on. Már a kezdetek kezdetén is. Én vezettem be. Én, aki törődött ezzel. Nem tetszett mindenkinek. Azóta nincs. Lehet SSL, nekem nem fáj. Viszont itt szeretném újra megjegyezni, hogy baromi sok minden ellen NEM VÉD. Ezért (sem) nem kell ide megadni semmilyen fontos adatot.

--
trey @ gépház

Ha már ennyire lovagolsz a biztonságon, akkor részedről annyit tehetsz a saját érdekedben a "kár minimalizálására", hogy nem az oldalon keresztül levelezel plain text-ben számodra érzékeny témában. A felelősség az adataidért nem csak az enyém, hanem a tiéd is. S valóban, abbahagyhatjuk.

--
trey @ gépház

"Ha már ennyire lovagolsz a biztonságon, akkor részedről annyit tehetsz a saját érdekedben a "kár minimalizálására", hogy nem az oldalon keresztül levelezel plain text-ben számodra érzékeny témában."
igy volt eddig is, igy lesz ezutan is (remelem ez a mondatod nem azt jelenti, hogy amit irtam egyes szam elso szelyben peldat, azt te ugy ertetted, hogy tenyleg en irogatom pm-ben az oldalon, hogy melyik munkahelyemrol loptam adatot. :P )

"A felelősség az adataidért nem csak az enyém, hanem a tiéd is. "
nyilvanvaloan.

over and out

Tyrael

Azért annyit kinézek a Drupal-ból hogy valami "globális" só van. Nem, nem néztem meg a forrást és igen, próbáltam már jelszavakat átemelni két Drupal installáció között és ment.

Szerk. Ledöbbentem. A sós kijelentésemet visszavonnám, kíváncsiságból utánanéztem a dolgoknak és úgy néz ki, plain md5-ben tárolódnak a jelszavak.

A mysql_real_escape_string legyen velünk! :)

Pedig a mai jelszomegjegyzos-OpenID-s vilagban viszonylag kis problema a jelszo. Az itteni jelszavammal sokra nem menne, mert azt masutt nemigen hasznalom, es ahol lehet, OpenID-vel regelek. Ettol mondjuk lehetne felnivalom, amennyiben az OpenID szolgaltatomat feltorik, de az a sejtes, hogy egy olyan pici kis ceg, mint a Verisign, hallott mar a biztonsagrol, es talan - talan! - kepes arra, hogy megvedjen engem a nagy es csunya internettol.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

legalabbis ha jol van megirva a webapp.
ha a jelszo modositasnal ott van a regi jelszo egy password tipusu input mezoben, akkor mar meg is van a jelszo.
ha lehet email cimet modositani jelszo megadasa nelkul, es az elfelejtett jelszo kuldes feature kikuldi az email cimre a regi jelszot plainbe, akkor megint csak buko.

Tyrael

MITM ellen az SSL egyáltalán nem védett. Hogy egy egyszerű példát mondjak már az ősrégi ISA server is képes volt ezt megcsinálni, beékelődött a kliens és a szerver közé és szépen eljárt a kliens nevében a szerver felé, majd az egész titkositott forgalmat pont ugyanúgy elemezte, loggolta, szűrte mint a nem titkositott kapcsolatot.

hat pedig ehhez az kellett imho, hogy az ISA-nal telepitve legyenek a private+public kulcsok, anelkul nem fogja tudni szetszedni majd osszerakni a https forgalmat.
persze ha csak halozati szinten forwardol, ahhoz nem kell tudni ertelmezni az alkalmazasretegben levo titkositott forgalmat, de akkor az nem is sikeres MITM.
szerintem.

kicsit maskeppen fogalmazva: ssl-lel vedett weboldalaknal is be tudsz ekelodni a kliens es a szerver koze halozati szinten, de a public kulcs nelkul nem tudod irni/olvasni a https-ses uzenetvaltasokat.
persze a forgalmat el tudnad terelni(manipulalod a nevfeloldast, vagy a tenyleges kiszolgalast), de ha en mint kliens https://hup.hu -t kerek a bongeszombol, akkor neked https-sel kell valaszolnod, kulonben a browserem elszall hibaval, ha pedig https-sel valaszolsz, akkor a cert amit kuldesz nem lesz megbizhato/valid ahhoz a domainhez. (persze ha elloptad a hup-hoz tartozo private kulcsokat, akkor mukodhet az is, de akkor mar a hup-ra is telepithettel volna valami malware-t)

Tyrael

Nezd a pszichologiai oldalat. Ha jol csinalod meg a MITM appot es csak olyan szolgaltatashoz telepited ahol csak a forgalom titkositasara hasznaljak es nincs cert. auth (mint a webes szolgaltatasok nagyon donto hanyada), akkor csak egy olyan certre van szukseged a kliensek fele amelyik valamelyik nagyobb cert kiadonal lett beszerezve, h a chain-t a bongeszok hitelesnek fogadjak el es ne rinyaljanak erte. Innentol kezdve tied a forgalom, mert a kutya sem fogja ellenorizni, h az adott https kapcsolatot milyen certtel epitettek fel. A magyar parlament IT szekcioja is csak ezen a bananhejon csuszott el. :)

---
pontscho / fresh!mindworkz

És ezt hogyan? Ahhoz, hogy a titkosított forgalomba bele tudjon nézni, vagy az kell, hogy ismerje a titkosításhoz használt kulcsot, vagy az, hogy a klienst rávegye, hogy ne a szerver számára titkosítson, hanem a középső ember számára.

Az elsőre, hogy neki megvan a szerver privát kulcsa, gondolom nem sok az esély.

A második akkor mehet, ha a kapcsolat felépülésekor a kliens számára ő jelentkezik be, mint távoli oldal, és a kliens megbízik a középső ember által mutatott tanúsítványban. Pl. a felhasználó elfogad egy self.signed certet, vagy mondjuk egy cégnél minden kliensen rajta van egy olyan CA kulcsa, amivel aláírt mindenre illeszkedő tanúsítványt mutat a céges proxy a kimenő kapcsolatokon.

Szóval hogy kell ennek a kivitelezését elképzelni mondjuk egy olyan helyen, ahol a rossz szándékú ember egy wifi hotspotot üzemeltet, és a beállított infrastruktúrával monitorozni akarja a felhasználók forgalmát? Mondjuk banki belépési adatokat akar lopni.

A céges gépre előtelepített céges cert az egy dolog.

De publikus helyen, saját géppel nem értem, hogy működne.

Amiket találtam google-lel, SSL mitm proxy pl. az on the fly generál self signed tanúsítványt.

Na de egy böngésző egy self signed certre rögtön kiabálni kezd, tehát már bukott is a dolog...

Lehet, hogy van más megoldás is, de nem láttam 5 perc keresés alatt.

Én nem tudnék ilyet gyártani, és eddig nem hallottam arról, hogy könnyen lehetne.

A fent javasolt google keresés 5 perc alatt nem hozott ilyen találatokat.

Esetleg egy URL-t küldhetnétek, hogy legalább azt lássam, hogy van ilyen, és megértsem, hogy működik.

(Az 5-ös és 6-os IE-ben levő hibát láttam, de tegyük fel, hogy friss és többféle böngészővel jönnek a felhasználók).

( Ghotler | 2011. 02. 26., szo – 21:04 )

Itt egy két helyen látva, többek felbuzdulását azért halkan hozzá tenném, nem biztos hogy az SSL minden esetben jó megoldás. Gondoljunk bele abba, hogy van egy alkalmazás szintű tűzfalunk, ha titkosítjuk a csomagokat, akkor a tűzfalunknak fogalma se lesz arról hogy mi van a csomagban, hanem szimplán tovább engedi. Nyilván ez is kiküszöbölhető.
Más különben úgy gondolom, ha valaki lopni szeretne vagy betörni, akkor annak több módját is választhatja. Ugyanis önmagában a tűzfal semmit se ér. Minimális védelmet ad! Mi döntsük el hogy mi megy be és mi jön ki, csak is rajtunk múlik, és azon hogy felismerjük-e hogy valaki, megpróbál bejutni hozzánk. Ehez elég egy olyan oldalra ellátogatnunk, vagy egy régebbi verziószámú böngészőt használnunk. De megfúrhatjuk mások wifi-jét bejutva a belső hálóra, és onnantól kezdve miénk a pálya.
Összegezve ezzel csak annyit akartam mondani, ha valaki be akar törni vagy elakar lopni valamit, és az a személy ért hozzá, az meg is fogja tenni.

[Szerk.:]Ja igen, ha valaki adott felhasználó adott jelszavát akarja megszerezni, nem biztos hogy a szervert támadja meg, úgy gondolom, sokkal könnyebb egy mezei user gépére betörni, mint egy "jól" tehát jól konfigurált szerverre.

WAF nyilvanvaloan a ssl mogott van, vagy ha nem, akkor rendelkezik a kulcsokkal, hogy bele tudjon halgatni a forgalomba, ez minden WAF-nal megoldott.

a tobbivel kapcsolatban:
igen, minden rendszert fel lehet nyomni kello agykapacitas es ido, penz birtokaban, nem mindegy azonban, hogy mennyire nehezitjuk meg a tamadok dolgat.
a formalis kockazatelemzes segitsegevel ki lehet szamolni, hogy mi az a raforditas az IT biztonsagra, ami meg megterul. nyilvanvaloan itt nem fog trey egy teljes kockazatelemzest vegezni, hanem kb. zsigerbol eldonti, hogy mi az ami meg megeri neki. ez igy egy modszer

nyilvanvaloan a hup-nak nem felelossege a felhasznalok desktopjainak vedelme, tehat bar ez egy erdekes es kevesse koztudatban levo resze a temanak, de itt offtopic.

Tyrael

Hadd kérdezzem meg, nem kötekedés képen, csak érdeklődés szinten, a téma iránt. Te mióta foglalkozol IT biztonsággal? Esetleg milyen tapasztalataid vannak, és milyen megoldásokat tudnál felsorolni egy szerver védelme érben, főleg a szoftveres védelmi eszközök és megoldások érdekelnének, de ha tudsz olyan hardveres eszközt mondani, amit egy magamfajta user is megtud venni, mert nem méreg drága (nem a routerre gondolok), akkor légyszíves írj pár sort ezekről.

webfejlesztokent dolgozom 5. eve foallasban, regota erdekel a tema, de nem tartom magam igazi expertnek, nem ez az elsodleges szakiranyom, de azert mar lattam jo/rossz rendszert mindket oldalrol (mint fejleszto, illetve mint "tamado").
a docler akademia keretein belul volt egy eloadasom a temaban, ha gondolod nezd meg a slideokat, vagy a videot (regisztracio, belepes szukseges a video megtekintesehez).
http://www.slideshare.net/Tyrael/biztonsgos-webalkalmazsok-fejlesztse
http://www.doclerholding.com/hu/academy/4/

a kerdesed igy nagyon tag, igazabol az implementacio a konkret rendszerttol fugg, az elmeleti alapok szerintem benne vannak a slide-ban, bar elsosorban fejlesztoi peldakra kihegyezve.

amugy az alapok ma is ugyanazok, mint regen, tudd hogy mit vedesz, kitol, a biztonsag ne utolag hozzaadott eszkoz legyen, hanem a rendszer kialakitasanak minden dontesenel figyelembe vett szempont.
a leheto legkevesebb szukseges szolgaltatas a szamukra szukseges leheto legkevesebb prioritassal fusson, egymastol leheto legjobban elszeparalva.
folyamatosan monitorozzuk a rendszerunk mukodeset, mivel akar egy eszrevetlenul vegrehajtott betorest is lefulelhetunk azaltal, hogy mondjuk megugrik a halozati forgalom egy olyan szegmensben, ahol ez nem jellemzo, etc.
legyen megfelelo audit trail, hogy kesobb visszakovethetoek legyenek akar a sikeres/sikertelen tamadasok, akar csak az, hogy ki dobta el az eles adatbazist.
ehhez ugye szukseges, hogy ne legyenek kozos accountok a rendszerben, illetve nem art, hogyha a kritikus muveletekhez 1-nel tobb embernek a jelenlete/jovahagyasa kell, ezaltal akar megoldhatoak a "who watches the watchmen" jellegu szituaciok (ertsd, ha az egy szem rendszergazda rossz utra ter, akkor nincs senki aki kiszurna, vagy megakadalyozhatna az ugykodeseben)

ja, es persze kepezzuk a dolgozokot, nagyon fontos kialakitani egy olyan dolgozoi paranoia-t, hogy jelszot sosem ker tole senki, es ha megis, akkor jelentse a felettesenek, etc.

ps: aki szemelyeskedeshez keresi a toltenyeket, az is nezze meg a videot, aztan lehet fikazni, hogy izgulok, meg neha nem a legjobb az angol kiejtesem. :P

Tyrael

Az előttem szólóhoz csatlakoznék.. jó az anyagod, köszönet érte.
Egyébként meg óvakodni kell a magukat expert-nek nevezőktől hidd el, mert X év után is, nem árt néha újra olvasni az alapokat.
Egy dolgot hiányoltam az anyagból, de lehet a video-n rajta van (meg fogom nézni), hogy sok támadás típusnál nem volt konkrét
példa, de nyilván ez nagyon nagy munka (lett) volna.

( kirsa74 | 2011. 02. 27., v – 09:46 )

1. "Volt már SSL a HUP-on. Már a kezdetek kezdetén is. Én vezettem be. Én, aki törődött ezzel. Nem tetszett mindenkinek. Azóta nincs. Lehet SSL, nekem nem fáj."

2. "Lehet én nem értek valamit, de akinek nem tetszik az nem használja, nem? Akinek meg kell az meg belép https -el."

->

Mi az akadalya annak, hogy legyen mindketto? Miert megy azon az erolkodes hogy A vagy B, mikor nem egymast kizaro opciokrol van szo?

De valoszinu en nem ertem.

"Mi az akadalya annak, hogy legyen mindketto?"

Gyakorlatilag semmi. De ez nem rajtunk múlik és Trey-nek is konzultálnia kell egy "feljebbvalójával"..
Én is használok olyan oldalakat, ahol be kell pipálni a "Biztonságos bejelentkezés (HTTPS)"-t és nem tartom rossz ötletnek. :-)

Szerintem egy ("belepes titkositott csatornan") pipa belefer, aki akarja hasznalja, aki akarja nem. Igy belefer akar egy self signed tanusitvany is. Ha olyan helyen ulok, hogy titkositas mentes wifi es tenyleg felek, hogy a mellettem ulo vezna srac, 3 hetes szorrel az arcan, hacker matricas laptopjaval elfogja lopni a jelszavaimat, akkor inkabb en is bepipalom es a tanusitvanyt is telepitem. Majd dolgom vegeztevel ranyomok a kilepes gombra es ennyi. Nem kotelezove teve, de elerhetokent szerintem lenne helyen, meg ha ilyen megoldasban is.
A lenyeg szerintem a lehetoseg megadasaban van, ha tenyleg szuksegesnek latom. Aki meg akarja hasznalni, telepitheti a cert-et is.

( taxy | 2011. 03. 04., p – 22:14 )

Ahogy beleolvastam mindenki a bejelentkezés miatt tartja fontosnak.
Akkor legyen csak a bejelentkezés https-en!
Egy időben a gmail is így működött. Most már ahogy nézem full https lett.

maskor olvasd vegig a szalat.
hint: http://hup.hu/node/99793#comment-1231791

ps: megcsinalni kb. ugyanannyi melo hogy csak a login legyen https, mint hogy minden.
cpu-ban/bandwith-ben lehet elteres, de szerintem 5-20% hasznalna szerintem csak az ssl-t, az meg nagysagrendileg nem novelne meg annyival, hogy ne erne meg megcsinalni.

Tyrael

+1 az OpenID-nek (amivel ráadásul az OTP is megoldódna, mert van olyan szolgáltató, aki támogatja)

Ha mégis esetleg saját https bejelentkezés lenne, akkor nehogy úgy legyen mint a freemail kapuja, ahol akkor lopom el a jelszót amikor akarom. Ha nincs keret teljes https-re, akkor a szegény ember dupla bejelentkezése a megoldás: sima http-n biztonságos bejelentkezésre kattint, átmegy https bejelentkező oldalra és ott írja be a jelszót, majd auth után vissza http-re. Tényleg elég lenne csak a jelszót levédeni, mert ez veti fel a legtöbb biztonsági problémát. Szerveren pedig egyedi salt mindenkinek + SHA.

Ja és cirkuszt és kenyeret! :)

En azt gondolom, hogy egy apache-nak baromira mindegy, hogy egy oldalt, vagy egy komplett site-t szolgal ki https-en, ebbol a szempontbol nem erzek problemat, hogy a komplett oldal menjen https-en. Az igazi koltseg maga a cert, amit azonban legfeljebb 1 domainre kell megvenni (hup.hu), tehat semmi specialis nincs benne (nem merul fel pl. a wildcard vagy nem wildcard kerdes).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

http://serverfault.com/questions/43692/how-much-of-a-performance-hit-fo…
persze nagyon sok fugg az adott szerver profiljatol (a dinamikus oldalak rendereleset nem dobja meg szazalekosan annyira a plusz ssl handshake, meg encryption, valamint pl. bekapcsolt KeepAlive-val lehet eleg sokat sporolni a handshake-bol fakado halozati ping-pong-on.), de ha teljes site-ot rakod ssl ala, akkor akar eleg jelentos overhead-je is lehetne.
ettol fuggetlenul szerintem megeri.

Tyrael

Manapság, amikor a session-lopások gyakoribbá válnak a jelszó lopásoknál, ennek nem hiszem, hogy túl sok értelme lenne. Talán már idecitálták, de úgy tűnik nem lehet elégszer:
http://en.wikipedia.org/wiki/Session_hijacking
és a top 10 kockázatok között többször is szerepel az ilyen vagy olyan session-lopás:
http://www.owasp.org/index.php/Top_10_2010-Main

Ettől függetlenül nem szabad figyelmen kívül hagyni, hogy a https igazán egy területen nyújt kiemelkedő védelmet: a nyílt, titkosítatlan wifi hálózatok használata esetén. Normál otthoni DSL-t vagy kábelt sokkal nehezebb lehallgatni. Ezeken túl még számtalan módon meg lehet támadni egy oldalt, illetve annak felhasználóit. A legtöbb felhasználó esetén valószínűbb a számítógépének a fertőzöttsége, mint a lehallgatása (persze ez talán nem igaz a HUP közösségére).

Ettől függetlenül én a https bevezetésére szavaznék, még ha csak olyan high-performance konfigurációban is, mint pl. a Facebook (RC4_128, MD5, RSA_1024).

És a StartSSL tökéletesen megfelel erre a célra ingyenesen. Nem kell telepíteni a böngészőkbe semmit, alapból ismeri mindegyik. Én is használom zárt adminisztrációs és statisztikákat biztosító oldalakhoz.

Igazad van, talán olvastam is, csak nem gondoltam végig.
Arra gondoltam, hogy a fórum üzeneteket felesleges titkosítani, egy terhelt szerver esetén biztos rádob egy konstans szorzófaktort.
De valóban, ha megszerzik a session-t akkor megváltoztathatják a jelszót, és így ott vagyunk ahol a part szakad. Jobb megoldás kell. :)

Keylogger ellen OTP segítségével lehet védekezni. Egyébként akit érdekel a téma az nézze meg szoftveres keyloggerrel mondjuk a CIB bejelentkezést és csodálkozni fog azon, amit lát. Ezen kívül hatezer mód van keylogger ellen védekezni (virtuális billentyűzet, logika vizuális jelszavak, stb..). Passzív támadást ma már nagyon könnyen ki lehet védeni. Célzott aktív támadásra pedig védekezzenek csak a bankok out of band channellel.

Megnézem mi ez az OTP, de a keylogger nem azt jelenti hogy kb megszerezték a "terminálomat", és tulajdonképpen azt csinálnak rajta amit akarnak, akár kernel modulokat is? De jó nem kötekedem, olvasok.

Szerk:
"OTPs are difficult for human beings to memorize. Therefore they require additional technology in order to work."

Jahhogy így más. :) Hát nekem nincs ilyen additional technology izém. :)

Kifogás2:

Jó de ha valaki annyira tart attól hogy meg van törve a "terminálja", hogy külön eszközt használ a bejelentkezéshez(Ez valami USB-s kütyü?). Akkor attól nem tart hogy ellopják a session-jét is? Akkor ezzel az erővel ezen a "kölön eszközön" kéne intézni a banki átutalást is, de akkor már ez egy laptop tudású gép.

( answ | 2011. 03. 05., szo – 22:07 )

OTP-hez elég egy Java ME képes mobil is.

CIB felülete billentyűleütéseket szimulál és ha csak hookolsz nem tudod megkülönböztetni a felhasználó és a gép által szimulált leütéseket (driver szinten kell dolgoznia a keyloggernek vagy hardver kell), így a jelszót sem tudod megszerezni így.