Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Interjú Wietse Venema-val

2008.09.30. 20:59 | buherator | 1 komment

A HUP-on már ki volt linkelve a SecurityFocus interjúja Wietse Venema-val, a fizikusból lett biztonsági szakértővel. A hajtás után olvashatjátok az interjú fordítását, okuljatok belőle!

Köszönet GHost-nak a fordításban nyújtott segítségért!

Wietse Venema fizikusnak készült, de később a saját fizikai kísérleteit irányító programjainak biztonsága kezdete érdeklni. Később,  Dan Farmer-el közösen készítettek néhány jól ismert hálózati biztonsági programot, mint például a Security Administrator's Tool for Analyzing Networks (SATAN) és a The Coroner's Toolkit. Venema a fejlesztője a Postfixnek és a TCP Wrapper-nek is. 

Federico Boancuzzi a Security Focus munkatársa beszélgetett Venema-val programok biztonságáról, arról hogyan lehetne javítani a kód minőséget, hogyan lehetne sikeresen harcolni a spam ellen, a legkevesebb privilégium elvéről és a Postfix tervezése mögött rejlő filozófiáról. Jelenleg Venema a IBM T.J Watson kutatólabor munkatársa.

Elmondanál néhány dolgot magadról?

A szerencse vitte az internet felé amikor a számítogép biztonság lassan kezdett gonddá válni. Lehetőségem volt hozzájárulni IT biztonsághoz néhány dologgal, mint például a TCP Wrapper, a SATAN, a Postfix és a The Coroner’s Toolkit. Ezek közül kettőt a SATAN-t és a TCT-t Dan Farmerrel együtt fejleszettük.
 
A fizikától jöttem, nem a számítástechnikától. Akkor tanultam programozni, mikor a saját kísérletemhez írtam a irányítást. Nagy körültekintéssel kellet a kódot írnom, mert a kísérlet órákat futott heteken keresztül és nem akartam a laborban tölteni minden percemet. Mikor megszereztem ezt a fajta tudást, már olyan volt mint a biciklizés: soha nem felejted el, hogy kell.

Sok vitát okozott a SATAN, mikor kiadtad '95-ben. A másik fejlesztőt Dan Farmert-t az akkori munkaadója, az SGI el is bocsájtotta. Mi a véleményed? Változott azóta az általános nézet a biztonsági programokról? 

Feltétlenül változott. A hálózati "letapogatás" egy elfogadott eszköz lett, ahogyan a tűzfalak, a behatolás érzékelők és a vírusirtók. Meggondolatlanság manapság ezeket az eszközöket figyelmen kívül hagyni.
Egy tökéletes világban nem lenne szükség ezekre az eszközökre, mert minden rendszer hibamentes lenne, de még nem értük el ezt a szintet. Modern Windows és Linux rendszerek 50-100 millió sor kódot tartalmaznak. Még a jó programozók is vétenek 1000 soronként 1 hibát, és évi több millió sornyi kóddal sokkal több hibát hozunk télre, mint ahányat kiírtunk.

Azt mondtad, volt egy időszak mikor “minden hálózati csomagot lementettél disk-re. Jó biztosítás.”.  Mi a véleményed? Egy ilyen nyilvános bejelentés elvenné a kedvét manapság egy támadónak?

Igen, de ez csak azokat a támadókat riasztaná el akik egy különleges oldalra akarnak bejutni. Manapság a legtöbb támadás nem célzott. Nem érdekli őket hová törnek be, a csomagjaikat folyamatosan naplózzák honypot-ok, és egyéb érzékelők, amik adatot gyűjtenek támadókról és veszélyes programokról. Teljes csomag naplózást csinál néhány rendszergazda is - természetesen főnöki engedéllyel, de ez sok helyet foglal el.
 
A saját hálózatomban az erőforrások túlságosan szűkek egy ilyen, válogatás nélküli naplózáshoz. Kevésbé érdekelnek a nem célzott támadások. Több megoldás kombinálásával próbálom biztonságban tartani hálózatomat mint például: egyszer használatos jelszavak, naplózás, alacsony jogosultságok, NAC (net access contorl).

Van-e kedvenc megoldásod,  a szoftver sebezhetőségek csökkentésére?

Mennél hamarabb sikerül elkapni egy hibát, annál jobb. Először fontos a  nagyon körültekintő tervezés és ellenőrzés. Másodszor, a forrás ellenőrző és futásidejű ellenőrző eszközök használata. Tapasztalatom szerint a legtöbb amit egy analizáló program tehet, hogy jobb programozóvá tesz. Vagyis még mindig lesz 1 hibád 1000 sorban.
Korábban már említettem, a programozásnak milliószor bonyolultabbnak kellene lenni, hogy csak AZ a néhány ember tudjon kódot írni. De ez nem az az irány amerre tartunk. Ehelyett egyre több és több ember, egyre kevesebb és kevesebb gyakorlattal lesz programozó, és a programjaik természetesen rá lesznek kötve az Internetre.
A kihívás az, hogy egy olyan környezetet teremtsünk a gyakorlatlan programozóknak, hogy nagyobb biztonsági lyukak nélkül tudjanak rendszereket fejleszteni. Manapság sokkal jobbak vagyunk az első részben, mint a másodikban. Viszonylag  könnyű egy PHP programot megírni, de nehéz mindezt tátongó biztonsági hibák nélkül megtenni. Végeztem már némi munkát, hogy javítsak ezen, de ne várjatok csodát.

Mi a  véleményed a most zajló spam-ellenes küzdelemről?

Egyedül az anti-spam eszközök nem fogják megoldani a problémát - mérsékelhetik ugyan a veszteséget, amit azok a a szervezetek és egyének elszenvednek, amelyek megengedhetik maguknak ezekez az eszközöket. A műszaki fegyverkezési verseny egészen addig fog folytatódni, amíg a politikusok és az igazságszolgáltatás kellő mértékben csatába nem szállnak, átlépve az országhatárokat.

Véleményem szerint az e-mail megbízhatósága 1998 környékén érte el a maximumát. Azóta csak lefelé tart az egyre agresszívebb anti-spam/vírus intézkedések következtében. Megfigyeléseim alapján azt mondhatom, hogy nem a spammerek rombolják az e-mail infrastruktúrát, hanem a jó szándékú emberek az ellenlépéseikkel.

Van olyan spam-ellenes technológia, amiről pozitív a benyomásod? Talán a Bayes-szűrés?

Adjuk ki a munkát emberi szemeknek! Jelen pillanatben ez a legjobb spam-ellenes technológia. Az emberek könnyen felismernek új mintákat - a számítógépeket újra kell programozni minden új trükknél, ami megkerüli a létező szűrőt. Természetesen az emberek is a hagyományos technikákat használják a nyilvánvaló szemét kiszűrésére. Jut eszembe, a spammerek is kiadhatják a munkát embereknek. Példának üsd be a "captcha porn" kifejezést a kedvenc keresődbe!

Gyakorlatban a DNS alapú IP blokk-listák számomra eliminálnák a spam nagy részét: a legtöbb internetes csomópont soha nem kell, hogy direkt e-mailt küldjön a neten keresztül. Ehelyett a szolgáltató szerverét kellene használniuk, ahol megfelelő szabályozást lehet érvényesíteni. Mostanában is tapasztaljuk, hogy a spammerek a felhasználók ISP jelszavaira pályáznak, hogy a postafiókokat spammelésre használhassák. A többi spam megfogható a zomik működési korlátai miatt, olyan módszerek használatával, mint pl. a szürke-listázás, nolisting, stb. Ezek a technikák minde megfogják az e-mailt, mielőtt még az a hálózatra kerülne, így viszonlag olcsók.

Az e-mail tartalomelemzést főleg arra használom, hogy megállítsam a rosszul üzemelő levelezőszerverekről visszaérkező, kézbesíthetetlen üzeneteket. Ezek a szerverek elfogadják az olyan spamet, ami azt állítja, hogy tőlem érkezik egy nem létező felhasználó részére,  majd segítőkész levelekben tájékoztatnak, hogy a keresett személy nem létezik.

Gondolod, hogy a probléma megoldható titkosítással?

Az autentikáció önmagában nem teszi az e-mail-t spam-mentessé, ahogy a kriptográfia sem teszi önmagában biztonságossá az Internetet. Az autentikáció lehetőséget ad arra, hogy megbizonyosodjak róla: a bankom nevével érkező levél tényleg a bankomtól jött. Az autentikáció azonban nem akadályozza meg a rosszindulatú feleket, hogy 100%-ig autentikus levelet küldjenek egy nagyon hasonló nevű banktól, ami egy nagyon hasonló kinézetű weboldallal rendelkezik. A spammerek például az SPF (sender permited from) első átvevői között voltak. Az autentikációs technikát ugyanígy azonnal, gond nélkül át fogják venni.

Mi a legjobb elméleti megoldás a problémára a te szemszögedből nézve?

A legjobb elméleti megoldás az, hogy megváltoztatjuk a terjesztési modellt, de ez talán soha nem fog megtörténni. Most az e-mail egy "toló" technológia, ahol nagyrészt a küldő irányít, és ahol a fogadó viseli a költség nagy részét.

Az alternatíva egy "húzó" modell, ahol a küldő a saját szerverén tárolja az üzeneteket egészen addig, amíg a fogadó fél le nem tölti azt. Például ha a bankom e-mailt akar nekem küldeni, küldhet egy rövid üzenetet egy URL-lel, amin megnézhetem a levelüket, a levelező szoftverem pedig le fogja tölteni ezt a levelet nekem. Persze feltételezzük, hogy a levelezőm felismeri a bankom e-mailjén a digitális aláírást, és az érvényes SSL bizonyítványukat, egyébként problémánk lenne az adathalászattal. Az elavult kliens szoftverek értesítenék a felhasználót, hogy üzenete érkezett, és a felhasználóra hagyná az üzenet letöltését.

A "húzó" modell megváltoztatná az e-mail "gazdaságát". A költség nagy részét áthelyezné a fogadó oldaláról - ahol most van - a küldő oldalára - ahová tartozik. Senki nem olvasna el olyan e-mailt, melynek küldője nem biztosít szolgáltatást az e-mail letöltésére.

És mi a legjobb amit tehetünk, hogy javítsunk a helyzeten? Bármi javaslat?

Tegyük másvalaki problémájává! Vizsgáld meg, hogy mennyi idő pazarlódik a spamre és negatív hatásaira, váltsd az időt pénzzé, és dönts el, hogy megengedheted-e magadnak, hogy más valaki végezze a szűrész helyetted?

Néhányan az MTA-jukkal [Mail Transfer Agent - levéltovábbító ügynök] együttműködő anti-spam és antivírus eszközöket használnak. Néhányan szeretik a dolgokat különválasztani, és külön rendszeren végzik a szűrést - nevezzük ezt IPS-nek [Intrusion Prevetion System] - ami több féle protokollt is szűr. Mi a véleményed erről a típusú szűrésről?

A társadalmunk azért haladt előre, mert az emberek specializálódtak. Valaki kenyeret süt, mások ruhát készítenek, van aki otthonokat épít, van aki utakat, és így tovább. Tulajdonképpen bármelyikünk el tudná végezni ezen dolgok mindegyikét, de az eredmény valószínűleg nem lenne olyan jó. Határozottan úgy gondolom, hogy jobb megoldásokat kapunk, ha különálló, specializált építőelemeket használunk, mintha egy mindenttudó rendszert akarnánk építeni.

Mi a véleményed a legkisebb jogosultság elvéről? "Meg vagyok győződve róla, hogy a legkisebb jogosultság elve alapvetően hibás" - ez egy idézet [Daniel J. Bernstein] egyik munkájából.
.
Véleményem szerint a legkisebb jogosultság elve néhány probléma esetében segít, más esetekben pedig nem. Például, ha egy levelező rendszer alacsonyabb jogosultsági szinten fut, egy támadás kevesebb bajt tud okozni a kiszolgáló rendszeren. Ez nagy dolog volt abban az időben, mikor még a Sendmail teljes jogkörrel futott, miközben évente több biztonsági hibát is találtak benne. Másrészt ez az elv nem segít olyan támadások esetében, amelyek a levelező rendszert helytelen e-mail kezelésre késztetik, például rossz embernek történő továbbításra, levelek elvesztésére, vagy a tartalom károsítására. Korlátozhatod az okozott kért a rendszer kisebb részekre particionálásával, de az egyetlen dolog ami tényleg segít az az, ha megakadályozod, hogy olyan hibák keletkezzenek, amiket egy támadó ki tud használni.

Milyen filozófia (elvek vagy elméletek) inspirált, mikor a Postfixet tervezted?

Sok dolog került a Postfix levelezőrendszerbe. Néhányat már meg is beszéltünk ebben az interjúban. Sok időt és helyet igényelne, hogy mindent átbeszéljünk, így most csak néhányat említek.

Koncepcionálisan a Postfix felépítése nagyon egyszerű. Úgy van felépítve, mint egy hálózati útválasztó, dedikált bemeneti interfészekkel, egy központi maggal, és dedikált kimeneti interfészekkel. Egy e-mail fogadásakor a bemenetek leszedik az SMTP, QMQP vagy UNIX szöveg formátum protokolfejléceket. A központi mag vezérli a várakozási sort és dönt arról,  hogy melyik kimeneti interfészt használjuk egy kiválasztott célhoz.  Végül a kimeneti interfészek hozzáadják az SMTP, QMQP vagy UNIX szövegformátum, vagy más protokoll számára szükséges adatokat miközben kézbesítik az üzenetet.

Ez a szervezés a Postfix daemon folyamat egy nagyon természetes dekompozíciójához vezet, ami jó a biztonság és a teljesítmény szempontjából is. Például minden ki- és bemeneti interfész külön daemon folyamatot kap kapcsolatonként és interfésztípusonként. A várakozási sort egy daemon folyamat vezérli, és van halom kis daemon processz, ami a több számár alát el feladatokat, mint pl. újracímzés, gyorsítótárazás, vagy SSL munkamenet-kezelés. Ezt az egészet egy master daemon folyamat felügyeli, amely igény szerint létrehozza a többi folyamatot.

Ez, a kis folyamatokba történő szervezés a hibakezelést is borzasztóan megkönnyíti azokhoz a levelezőrendszerekhez képest, melyek egyszerre több kézbesítést végeznek egy nagy folyamaton belül. A master folyamaton kívül minden más Postfix folyamat eldobható: ha belefutnak valamilyen hibába, azonnal meg tudnak "halni" [die()] a master majd helyettesíti őket. Nincs elveszett üzenet, és a levelezőrendszer többi része működik tovább. Olyan ez mint az a gumibelső, ami képes az apró lyukakat befoltozni magán anélkül, hogy meg kellene állnunk.

Az egyik lecke amit megtanultam ezen projekt folyamán az az, hogy biztos kiterjesztési felületeket kell biztosítani. Ez lehetőv teszi, hogy a szolgáltatók olyan speciális szoftverekkel egészítsék ki a rendszert, amiket én nem akarok megírni, mint pl. anti-spam/vírus, vagy digitális aláírás. Ez a szoftver élettartamát is kiterjeszti. A Postfixben hagyományosan viszonylag gyakran találnak sebezhetőséeg, ami kényszerű frissítésekhez vezethetne, ami azért jó, mert a kiszolgálók frissíthetnek egy alárási protokollt anélkül, hogy az egész rendszert le kéne cserélniük. Ahogy az előbbi példámban a specializációról, ahol a különböző emberek emberek kenyeret vagy ruhákat készítettek, a specializáció jobb inőségű szoftver elkészítését teszi lehetővé.

 

Címkék: spam postfix wietse venema

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

helios 2008.09.30. 23:27:44

Na, ILYEN egy leet!

Respect!
süti beállítások módosítása