17 i 19, obychno ispol'zuemyj dlya start-signala(XON) i stop-signala(XOFF)) dolzhno byt' escaped, to Vam nado ispol'zovat' sleduyushchuyu opciyu: Asyncmap 0x000A0000 Maksimum poluchaet edinicu, ili MRU, soobshchaet peer maksimal'nyj razmer HDLC ramki, kotoruyu my hotim poluchit'. Hotya eto mozhet napomnit' Vam znachenie MTU (Maksimal'naya Porciya obmena), to eti dva imeet nemnogo obshchego. MTU - parametr kernel ustrojstva raboty s setyami, i opisyvaet maksimal'nuyu strukturu inerface delaya ego sposobnym k obrabotke. MRU bolee, chem soveta k remote end dlya togo, chtoby ne generirovat' lyuboj frejm bol'shij chem MRU; interface dolzhen odnako byt' sposoben 1500 bajt. Vybor MRU ne takoj bol'shoj vopros togo chto kak svyaz' sposobna k peresylke, no togo, chto dast Vam samyj luchshij throughput. Esli Vy imeete v vidu interaktivnye prilozheniya nad svyaz'yu, to ustanovki MRU k znacheniyam vsego 296 - horoshaya ideya, tak, chtoby sluchajnyj bol'shij blok (govoryat, iz FTP seansa) ne sdelal by vash kursor "jump''. CHtoby soobshchit' - 155 - pppd chtoby on zaprosil MRU 296, Vy by dali emu opciyu mru 296. Malyj MRUs, odnako, tol'ko imeet smysl, esli Vy ne imeete etu opciyu (eto otklyuchaetsya po umolchaniyu). Pppd ponimaet takzhe paru LCP opcij, kotorye konfiguriruyut polnoe povedenie processa peregovorov, tipa maksimal'nogo nomera iz zaprosov konfiguracii, kotorye mogut byt' obmeneny pered tem kak svyaz' budet prervana. & " V zaklyuchenie, imeyutsya dve opcii, kotorye obrashchayutsya k LCP ECHO soobshcheniyam. PPP opredelyaet eti dva soobshcheniya, zapros ECHO i otvet ECHO. Pppd ispol'zuet etu osobennost', chtoby proverit', dejstvuet li svyaz' vse eshche. Vy mozhete otklyuchit' eto ispol'zuya opciyu lcp-echo-interval vmeste so vremenem mgnovenno. Esli nikakie struktury ne polucheny ot otdalennogo hosta vnutri etogo intervala, to pppd sgeneriruet zapros ECHO, i budet ozhidaet, kakoj ECHO otvet peer vozvratit. Esli peer ne vozvrashchaet otvet, to svyaz' budet prervana posle nekotorogo chisla poslannyh zaprosov. |tot nomer mozhet byt' ustanovlen ispol'zuya opciyu lcp-echo-failure. Po umolchaniyu, eta osobennost' otklyuchena v celom. 9.9 Obshchie rassmotreniya zashchity Ploho skonfigurirovannyj PPP daemon mozhet byt' razrushitelen dlya zashchity. |to mozhet byt' tak ploho, kak razreshenie podsoedinit'sya lyubomu cheloveku so svoego komp'yutera v Vashu Ethernet (i eto ochen' ploho). V etom razdele, my obsudim neskol'ko kriteriev, kotorye dolzhny sdelat' vashu PPP konfiguraciyu bezopasnoj. Odna problema s pppd - to, chto konfiguraciya setevogo ustrojstva i tablicy marshrutov trebuyut privilegii root. Vy budete obychno razreshat' etu slozhnost', vypolnyaya setuid root. Odnako, pppd pozvolyaet pol'zovatelyam ustanovit' razlichnye zashchita-relevantnye opcii. Dlya zashchity protiv lyubogo napadeniya, pol'zovatel' mozhet manipulirovat' etimi opciyami, Vam predlozhat ustanovit' paru znachenij po umolchaniyu v global'nom fajle /etc/ppp/options, podobno tem pokazannym v tipov 9.4. Nekotorye iz nih, tipa opoznavatel'nyh opcij, ne mogut byt' - 156 - otmeneny pol'zovatelem, i tak chto oni obespechivayut priemlemuyu zashchitu protiv manipulirovanij. Konechno, Vy dolzhny zashchitit' sebya ot sistem, s kotorymi PPP takzhe obshchaetsya. CHtoby otrazit' hosty, Vy dolzhny vsegda imet' nekotoryj vid ustanovleniya podlinnosti ot vashego peer. Dopolnitel'no, Vy ne dolzhpy pozvolyat' inostrannym hostam ispol'zovat' lyuboj adres IP kakoj oni vyberut, no ogranich'te ih po krajnej mere neskol'kimi. Sleduyushchij razdel budet svyazam s etimi problemami. 9.10 Ustanovlenie podlinnosti s PPP .10.1 CHAP protiv PAP S PPP, kazhdaya sistema mozhet trebovat', chtoby peer opoznal sebya ispol'zuya odnin iz dvuh opoznavatel'nyh protokolov. Oni - (PAP), i (CHAP). Kogda svyaz' ustanovlena, kazhdyj mozhet zaprosit' drugoj, chtoby opoznat' sebya, nezavisimo ot togo, yavlyaetsya li eto caller ili callee. Nizhe ya budu govorit' o "kliente " i " servere " kogda ya zahochu sdelat' razlichie mezhdu sistemoj opoznaniya i authenticator. PPP daemon mozhet sprashivat' peer otno podlinnosti, posylaya odnako drugoj LCP zapros konfiguracii, opoznavayushchij zhelaemyj protokol. PAP v osnovnom rabotaet v tom zhe samom sposob kak normal'naya procedura vhoda v sistemu. Klient opoznaet sebya, posylaya imya pol'zovatelya i parol' kserveru, kotoryj sravnivaetsya s bazoj dannyh sekretov. |tot metod legkouyazvim k eavesdroppers, kotoryj mozhet popytat'sya poluchit' parol', slushaya posledovatel'nuyu liniyu, i k povtoreniyu ispytaniya i resheniya oshibki. CHAP ne imeet etih nedostatkov. S CHAP, authenticator (to est' server) posylaet besporyadochno sgenerirovannuyu " challenge'' stroku k klientu, naryadu s hostname. Klient ispol'zuet hostname dlya togo, chtoby iskat' sootvetstvuyushchij shifr, ob®edinyaya eto s challenge, i shifruya stroku, ispol'zuya odnonapravlennuyu hashing function. Rezul'tat budet vozvrashchen na server naryadu s hostname klienta. Server teper' vypolnyaet to zhe samoe vychislenie, i podtverzhdaet klienta. - 157 - Drugaya osobennost' CHAP - to, chto on ne trebuetsya opoznaniya klienta dlya opoznaniya samogo sebya pri zapuske, no posylaet challenges v opredelennye promezhutki vremeni, chtoby udostoverit'sya ne byl klient zamenen "zloumyashlepnikom ", naprimer, tol'ko pereklyuchaya telefonnye linii. Pppd hranit sekretnye klyuchi dlya CHAP i PAP v dvuh otdel'nyh fajlah, vnazyvaemyh /etc/ppp/chap-secrets i pap-secrets sootvetstvenno. Vhodom otdalennogo hosta v odin ili drugoj fajl, Vy imeete horoshij kontrol' nad CHAP ili PAP prednaznachennyj dlya etogo, chtoby opoznat' nas s nashim peer, i naoborot. Po umolchaniyu, pppd ne trebuet ustanovleniya podlinnosti ot remote, no soglashaetsya opoznavat' sebya kogda zaprosheno remote. Tak kak CHAP namnogo bolee sil'na chem PAP, pppd probuet ispol'zovat' vysheupomyanutyj vsyakij raz, kogda eto vozmozhno. Esli peer etogo ne podderzhivaet, ili esli pppd ne mozhet najti CHAP shifr dlya remote sistemy v fajle shifrov chap, on vozvrashchaetsya k PAP. Esli on imeet PAP shifr dlya peer takzhe, to on otkazhetsya opoznavat' v celom, i kak sledstvie, svyaz' zakroetsya. |to povedenie mozhet byt' izmeneno otdel'nymi sposobami. Naprimer, kogda daetsya auth klyuchevoe slovo, pppd trebuet, chtoby peer opoznal sam sebya. Pppd soglasitsya ispol'zovat' ili CHAP ili PAP dlya etogo, kak tol'ko eto budet imeet shifr dlya peer v CHAP ili v baze dannyh PAP sootvetstvenno. Imeyutsya drugie opcii, chtoby vklyuchit' ili vyklyuchit' chastnyj opoznavatel'nyj protokol, no ya ne budu opisyvat' ih zdes'. Pozhalujsta obratites' k pppd (8) dlya detalej. Esli vse sistemy, s kotorymi Vy govorite PPP, soglashayutsya opoznavat' samih sebya s Vami, Vy dolzhny pomestit' opciyu auth v global'nyj fajl /etc/ppp/options i opredelit' paroli dlya kazhdoj sistemy v fajle shifrov chap. Esli sistema ne podderzhivaet CHAP, dobav'te zapis' k fajlu pap shifrov. Takim obrazom, Vy mozhete udostoverit'sya v tom, chto nikakaya neopoznannaya sistema ne soedinyaetsya s Vashim hostom. - 158 - Sleduyushchie dva razdela obsuzhdayut dva PPP fajla shifrov, pap- secrets i chap-secrets. Oni razmeshchzny "v /etc/ppp i soderzhat trojki klientury, serverov i parolej, neobyazatel'no soprovozhdaemyh spiskom iz adresov IP. Interpretaciya klienta i oblastej servera otlichna dlya CHAP ili PAP, i takzhe zavisit ot togo, opoznaem li my sebya samostoyatel'no s peer, ili potrebuem opoznat' server neposredstvenno s nami. 9.10.2 Fajl shifrov CHAP Kogda eto dolzhno opoznat' sebya s nekotorym serverom, ispol'zuya CHAP, rppd ishchet fajl shifrov PAP dlya zapisi s klientskoj oblast'yu ravnoj lokal'nomu hostname, i oblasti servera ravnoj k remote hostname poslannyj v CHAP Challenge. Pri trebovanii peer k opoznavaniyu sebya, roli prosto pomenyalis': pppd budet zatem iskat' zapis' s klientskoj oblast'yu priravnennoj k otdalennomu hostname (poslannyj v CHAP otvet klientu) i oblast' servera priravnennoj lokal'nomu hostu. Sleduyushchee - tipovoj fajl shifrov chap dlya vlager: (9) # CHAP secrets for vlager.vbrew.com # # client server secret addrs #------------------------------------------------------------------- --- vlager.vbrew.com c3po.lucas.com "Use The Source Luke" vlager.vbrew.com c3po.lucas.com vlager.vbrew.com "riverrun, pasteve" c3po.lucas.com * vlager.vbrew.com "VeryStupidPassword" pub.vbrew.com Pri ustanovlenii PPP svyazi s c3po, c3po zaprashivaet vlager opoznat' sebya, ispol'zuya CHAP, posylaya CHAP challenge. Pppd zatem prosmatrivaet chap shifry dlya zapisi s klientskoj oblast'yu, priravnenoj k vlager.vbrew.com i oblast'yu servera priravnennoj k c3po.lucas.com, (10) i nahodit - 159 - pervuyu liniyu, pokazannuyu vyshe. Zatem proizvoditsya CHAP otvet ot challenge string i shifra (Ispol'zujte Istochnik Luke), i posylaet ot c3po. V to zhe samoe vremya, pppd sostavlyaet CHAP challenge dlya c3po, soderzhashchuyu unikal'nuyu challenge string, i pplnout'yu kvalificirovannyj hostname vlager.vbrew.com. C3po sozdaet CHAP otvet sposobom, kotoryj my tol'ko chto obsudili, i vozvrashchaet eto k vlager. Pppd teper' izvlekaet klientskij hostname (c3po.vbrew.com) iz otveta, i poiskov fajlov shifra chap dlya linii, sootvetstvuyushchej c3po kak klient, i vlager kak server. Vtoraya liniya delaet tak chto pppd ob®edinyaet CHAP challe pasteve, shifruet ih, i sravnivaet rezul'tat s s3po CHAR otveta. Proizvol'naya chetvertaya oblast' perechislyaet adresa IP, kotorye yavlyayutsya dlya klientury, imenovannoj v pervoj oblasti. Adresa mogut byt' dany v dotted quad notation ili kak hostnames, kotorye razyskskany s pomoshch'yu reshayushchego ustrojstva. Naprimer, esli zapros c3po, na ispol'zovanie IP adresa vo vremya IPCP peregovora, kotoryj ne v etom spiske, zapros budet otklonen, i IPCP budet vyklyucheno. V tipovojfajle, pokazannom vyshe, s3po sledovatel'no budet ogranichen ispol'zovaniem sobstv Esli oblast' adresa pusta, lyubye adresa budut pozvolyat'sya, znachenie kotoryh - predotvrashchaet ispol'zovanie IP s klientom. Tret'ya liniya v primere fajle shifrov chap pozvolyaet lyubomu hostu ustanovit' svyaz' PPP s vlager potomu chto klient ili oblast' servera sootvetstvuet hostname. Edinstvenoe trebovanie - to, chto on znaet parol', i ispol'zuet adres pub.vbrew.com. Vhod s gruppovym simvolom hostnames mozhet poyavitsya gde-nibud' v fajle shifrov, tak kak pppd budet vsegda ispol'zovat' naibolee specificheskuyu zapis', kotoraya primenyaetsya k pare servera / klienta. 9. Dvojnye kavychki - ne chast' parolya, oni prosto sluzhat dlya togo, chtoby zashchitit' nezapolnennoe prostranstvo vnutri parolya. 10. |tot hostname prinimaetsya iz CHAP challenge. Imeyutsya nekotorye slova, kotorye nuzhno upominut' otnositel'no sposoba, kotorym pppd dostigaet hostnames: on ishchet v fajle shifrov. - 160 - Kak bylo ob®yasneno prezhde, otdalennyj hostncme vsegda obespechivaetsya peer v CHAP Challenge ili v Response packet. Lokal'nyj hostname budet poluchen, esli vyzvat' gethostname funkciyu (2) po umolchaniyu. Esli Vy ustanovili nazvanie sistemy Vashemu nekvalificirovannomu hostname, to Vy dolzhny obespechit' ego pppd oblast'yu. # pppd ...domain vbrew.com |to konkateniruet nazvanie Brewery oblasti k vlager dlya vseh ustanovlenyh podlinnost'yu dejstviya. Drugie opcii, kotorye modificiruyut progpppd's idea otnositel'no lokal'nogo hostname - usehostname i name. Kogda Vy daete lokal'nyj IP adres na komandnoj stroke, ispol'zuyushchej "local:varremote", i local - nazvanie vmesto dotted quad, pppd ispol'zuet eto kak lokal'nyj hostname. Dlya detalej, pozhalujsta obratites'k pppd stranice spravochnika (8). 9.10.3 Fajl shifrov PAP. Fajl shifrov PAP ochen' pohozha na tot, kotoryj ispol'zuetsya CHAP. Snachala dve oblasti vsegda soderzhat nazvanie pol'zovatelya i nazvanie servera; tret'ya chast' zaderzhivaet shifr PAP. Kogda remote posylaet opoznayushchijsya zapros, rppd ispol'zuet zapis', kotoraya imeet oblast' servera ravnoj lokal'nomu hostname, i oblast' pol'zovatelya priravnennoj k imeni pol'zovatelya, poslannomu v zaprose. Kogda opoznanie sebya s peer proizojdet, pppd vyberet shifr, kotoryj budet poslan iz linii s oblast' priravnennoj k lokal'nomu imeni pol'zovatelya, i oblast'yu servera priravnennoj k remote hostname. Tipovoj fajl shifrov PAP mog by vyglyadit' sleduyushchim obrazom: # /etc/ppp/pap-secrets # # user server secret addrs vlager-pap c3po cresspahl vlager.vbrew.com c3po vlager DonaldGNUth c3po.lucas.com Pervaya liniya ispol'zuetsya dlya togo, chtoby opoznat' nas kogda my govorim s s3ro. - 161 - Vtoraya liniya opisyvaet, kak pol'zovatel' imennovannyaj c3po, dolzhen byt' opoznanym neposredstvenno s nami. Imya vlager-pap v stolbce, kotoryj yavlyaetsya imenem pol'zovatelya, my posylaem k c3po. Po umolchaniyu, pppd vyberet lokal'nyj hostname kak imya pol'zovatelya, no Vy mozhete takzhe opredelit' razlichnye nazvaniya, davaya opciyu pol'zovatelya, soprovozhdaemuyu eti imenem. Pri vybore zapisi iz fajla shifrov PAP registriruyutsya dlya ustanovleniya podlinnosti s peer, pppd dolzhen znat' nazvanie remote hosta. Poskol'ku eto ne imeet sposoba nahozhdeniya togo, chto Vy dolzhny tochno opredelit' na etoj komandnoj stroke, ispol'zuyae remotename klyuchevogo slova, soprovozhdaemogo hostname peer. Dlya obrazca, kak ispol'zovat' vysheupomyanutuyu zapis' dlya ustanovleniya podlinnosti s c3po, my dobavlyaem opciyu sledovaniya k komandnoj stroke pppd's: \#{} pppd ... remotename c3po user vlager-pap V chetvertoj oblasti (i vse sleduyushchie oblasti), Vy mozhete tochno opredelit' kakie adresa IP razresheny dlya togo chastnogo mnozhestva, tochno kak i v fajle shifrov CHAP. Peer mozhet zatem tol'ko zaprosit'' adresa iz etogo spiska. V tipovom fajle, my trebuem, chtoby c3po ispol'zoval real'nyj adres IP. Zamet'te, chto PAP dovol'no slabyj opoznavatel'nyj metod, i eto predpolagaet vsyakij raz, kogda Vy ispol'zuete CHAP, esli eto vozmozhno. My ne budem sledovatel'no opisyvat' PAP v detalyah zdes'; esli Vy zainteresovany v ispol'zovanii PAP, Vy najdete neskol'ko bol'she v pppd stranice spravochnika (8). 9.11 Konfigurirovanie PPP servera Pri zapuske pppd, poskol'ku server - tol'ko sushchnost' dobavleniya sootvetstvuyushchej opcii k komandnoj stroke. Bylo by ideal'nym, esli Vy sozdali by special'nyj account, skazhem ppp, i - 162 - dadite etomu script ili programme kak obolochke vhoda v sistemu, kotoraya vyzyvaet pppd s etimi opciyami. Naprimer, Vy by dobavili sleduyushchuyu liniya k /etc/passwd: " ppp:*:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin Konechno, Vy mozhete zahotet' ispol'zovat' bolee universal'nye uids i gids chem te, chto pokazanny vyshe. Vy takzhe byli by dolzhny ustanovit' parol' dlya vysheupomyanutogo account, ispol'zuyushchego komandu passwd. Ppplogin script mozhet byt' vyglyadit' sleduyushchim obrazom: #!/bin/sh # ppplogin - script to fire up pppd on login mesg n stty -echo exec pppd -detach silent modem crtscts Komanda mesg blokiruet drugih pol'zovatelej, chtoby zapisat' k tty, ispol'zuya, na primer, komandu zapisi. Komanda stty vyklyuchaet znako-otobrazhenie na ekrane. |to neobhodimo, potomu chto inache peer vse posylal by ispol'zuya otobrazhenie na ekrane. Naibolee vazhnaya opciya pppd, dannaya vyshe -detach, potomu chto eto predotvrashchaet pppd ot otsoedineniya iz upravleniya tty. Esli my ne tochno opredelim etu opciyu, eto budet idti k predposylke, sozdaniya shell script exit. |to bylo k zavisaniyu. Silent opciya zastavlyaet pppd zhdat', poka on ne poluchit blok ot sistemy vyzova prezhde, chem eto nachinaet posylat'. |to predotvrashchaet ot blokirovki po vremeni, kogda sistema vyzova medlena v obsluzhivanii PPP nablyudat' DTR liniyu, chtoby videt', ponizil li peer svyaz', i crtscts vklyuchaet apparatnoe rukopozhatie. Pomimo etih opcij, Vy mogli by zahotet' vynudit' nekotoryj vid opoznaniya, naprimer, tochno opredelyaya auth na komandnoj stroke pppd's, ili v global'nom fajle opcij. Rukovodstvo takzhe obsuzhdaet bolee specificheskie opcii dlya vkl. ili vykl. individual'nyh opoznavatel'nyh protokolov. - 163 - 10. Razlichnye setevye prilozheniya Posle uspeshnoj ustanovki IP i reshayushchego ustrojstva, Vy dolzhny obratit'sya k uslugam obespechivayushchim horoshuyu rabotu nad set'yu. Glava nachinaetsya s konfigurachiya peskol'kih prostyh setevyh prilozhenij, vklyuchaya Inetd server, i programmy iz rlogin sovokupnosti. Neznachitel'naya procedura obrashcheniya svyazyvaet, s pomoshch'yu interfejsa, eti uslugi podobno Setevoj Fajlovoj sisteme (NFS). Setevaya Informacionnaya Sistema (NIS) osnovana na tom zhe samom, imela delo s briefly. Konfiguraciya NFS i NIS, odnako berushchyaya bol'shoe kolichestvo pamyati, budet opisana v otdel'nyh glavah. |to primenyaetsya k elektronnoj pochte i netnews takzhe. Konechno, my ne mozhem opisat' vse setevye prilozheniya v etoj knige. Esli Vy hotite ustanavit' to, kotoroe ne obsuzhdaetsya zdes', podobno peregovoram, gopher, ili xmosaic pozhalujsta obratites' k rukovodstvu dlya detalej. 10.1 Inetd super-server CHasto, uslugi predostavlyayutsya tak nazyvaemymi daemons. Daemon yavlyaetsya programmoj, kotoraya otkryvaet nekotoryj port, i svyaz'. Esli eto proishodit, eto sozdaet dochernij process, kotoryj prinimaet svyaz', v to vremya kak osnovnoj prodolzhaet zhdat' dal'nejshih zaprosov. |to ponyatie imeet nedostatok chto dlya kazhdogo predlagaemogo obsluzhivaniya, daemon dolzhen zapuskat' te, kotorye slushayut porte dlya svyazi, dlya kotoryh eto voobshche oznachaet poteri sposobov sistemy podobno prostranst Takim obrazom, pochti vsya Un*x installyaciya zapuskaet " super- server ", kotoryj sozdaet gnezda dlya ryada uslug, i slushaet na nih odnovremenno pri ispol'zovanii otobrannogo sistemnogo vyzova (2). Kogda otdalennyj host zaprashivaet odnu iz uslug, super-server zamechaet etot i porozhdaet drugoj server, tochno ustanovlennyj dlya etogo porta. Super-server, obychno ispol'zuemyj - inetd, Internet Daemon. |to nachinaetsya pri nachal'noj zagruzke sistemy, i beret spisok uslug, k - 164 - kotorym on obrashchaetsya iz fajla zapuska, imenovannoj /etc/inetd.conf. V dopolnenie k tem vyzyvaemym serveram, tam est' ryad trivial'nyh uslug, kotorye yavlyayutsya na sformirovavshimsya inetd, neppsrezhstvenno vyzyvaemym vnutrennie uslugi. Oni vklyuchayut chargen kotoryj prosto generiruet ryad znakov, i daytime kotoryj vozvrashchayut system's idea Zapis' v etoj kartoteke sostoit iz edinstvennoj linii, sdelannoj iz sleduyushchej oblasti: service type protocol wait user server cmdline Znachenie kazhdoj oblasti sleduyushchie: Service daet servisnoe imya. Service name dolzhno byt' perevedeno k nomeru porta, prosmatrivaya v fajle services. |tot fajl budet opisan v razdele 10.3. type opredelyaet tip gnezda, lyuboj potok (dlya svyaz'- orientiruemyh protokolov) ili dgram (dlya datagramnyh protokolov). TCP osnovanna na uslugah, kotorye dolzhny vsegda ispol'zovat' potok, v to vremya kak UDP-osnovannye uslugi dolzhny vsegda ispol'zovat' dgram. Protocol nazyvaetsya protokolom perenosa, ispol'zuemym obsluzhivaniem. |to dolzhno byt' podhodyashchim nazvaniem protokola, najdennoe v fajle protokolov, takzhe ob®yasneno nizhe. wait eta opciya primenyaetsya tol'ko na dgram gnezdah. |to mozhet byt' takzhe wait ili nowait. Esli wait opredelen, to inetd tol'ko vypolnit odin server dlya tochno ustanovlennogo porta v lyuboe vremya. Inache, eto nemedlenno prodolzhit slushat' na porte posle izvlecheniya servera. |to polezno dlya "edinstvenno - svyaznnyh " serverov, kotorye chitayut vse vhodyashchie datagrammy, i zatem vyhodyat. Bol'shinstvo RPC serverov imeet etot tip i dolzhny sledovatel'no tochno opredelit' wait. Protivopolozhnyj tip, "mnogopotochnye " servery, pozvolyaet bezgranichnomu chislu obrazcov, chtoby byt' zapushchennymi odnovremenno; no eto redko kogda - 165 - ispol'zuetsya. |ti servery dolzhny tochno opredelit' nowait. Gnezda potoka dolzhny vsegda ispol'zovat' nowait. User eto yavlyaetsya identichnost'yu vhoda v sistemu pol'zovatelya, ob®yasnennyj nizhe. |to budet chasto root user, no nekotprye" uslugi mogut ispol'zovat' razlichnye account. |to - ochen' horoshaya ideya k primeneniyu principa naimen'shego kolichestva privilegii zdes', kotoryj zayavlyaet chto Vy ne dolzhny zapuskat' komandu nizhe privilegirovannogo account esli programma ne trebuet etogo dlya prisushchego funkcionirovaniya. Dlya primera, NNTP server novostej budet zapuskat' novosti, poka us risk zashchity (tipa tftp, ili finger) budut upravlyat'sya kak nobody. server daet polnyj put' programmy servera, kotoraya budet vypolnena. cmdline eto- komandnaya stroka, kotoruyu nuzhno zapustit' na servere. Ona vklyuchaet argument 0, kotoryj yavlyaetsya nazvaniem komandy. Obychno, eto ne budet nazvaniem programmy servera, esli programma vedet sebya po-drugomu, kogda vyzyvaetsya s razlichnym imenem. |ta oblast' pusta dlya vnutrennih uslug. Tipovoj inetd.conf fajl izobrazhen na risunke 10.1. Finger service prokommentirovannog tak chtoby eto bylo ne dostupno. |to chasto vypolnyaetsya iz soobrazhenij bezopasnosti, potomu chto mozhet ispol'zovat'sya napadavshimi dlya togo, chtoby poluchit' imya pol'zovatel i na vashej sisteme. Tftp imzobrazheno prokommentirovannym takzhe. Tftp osushchestvlyaet Primitivnyj Protokol Peredachi fajla, kotoryj pozvolyaet peredavat' lyubye vsemirno - chitaemye fajly iz vashej sistemy bez parolya. |to osobenno vredno dlya fajla /etc/passwd, dazhe bolee togo, kogda Vy ne ispol'zujte tenevoj parol'. TFTP obychno ispol'zuetsya klienturoj bez diska i X terminalami pri zagruzke ih koda iz servera pri nachal'noj zagruzke. Esli Vy dolzhny zapustit' tftpd dlya etoj problemy, udostoverites', chto ogranichennaya - 166 - oblast' dejstviya k direktoriyam klientov budet vosstanovlena iz fajlov, dobavlyaya te nazvaniya katalogov k komande tftpd's linii. |to pokazano vo vtoroj tftp linii v primere. 10.2 Tcpd sredstva upravleniya dostupom " Nachinaya s otkrytiya komp'yutera k seti sredstvo vovlekaet mnogo zashchity, prilozheniya razrabotannye tak, chtoby prinyat' mery protiv tipov resheniya. Nekotorye iz etih, odnako, mogut byt' flawed (naibolee reshitel'no demonstrirovannymi RTM Internet worm), ili mogut ne razlichat'sya mezhdu bezopasnymi hostami, iz kotoryh pros'by o chastnom obsluzhivanii budut prinyaty, i opasnymi hostami, ch'i zaprosy dolzhny byt' otkloneny. My uzhe kratko obsuzhdali finger i tftp uslugi vyshe. # # inetd services ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd - b/etc/issue #finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd /boot/diskless login stream tcp nowait root /usr/sbin/rlogind in.rlogind shell stream tcp nowait root /usr/sbin/rshd in.rshd exec stream tcp nowait root /usr/sbin/rexecd in.rexecd # # inetd internal services # daytime stream tcp nowait root internal daytime dgram udp nowait root internal time stream tcp nowait root internal time dgram udp nowait root internal echo stream tcp nowait root internal echo dgram udp nowait root internal discard stream tcp nowait root internal - 167 - discard dgram udp nowait root internal chargen stream tcp nowait root internal chargen dgram udp nowait root internal Ris. 15. /etc/inetd.conf file. ogranichit' dostup k etim uslugam " doverennye mnozhestva " tol'ko, kotorye nevozmozhny s obychnoj ustanovkoj, gde inetd obespechivaet etu zashchitu vsej klienture. &Polzznoe sredstvo dlya etogo - tcpd, (1), tak nazyvaemyj daemon wrapper. Dlya TSP uslugi Vy hotite prokontrolirovat' ili zashchishchat' ego, vyzyvaya vmesto ego programmu servera. Tcpd regestriruet zapros k syslog daemon, proveryaya pozvolyayut li remote hostu ispol'zovat' obsluzhivanie, i tol'ko esli eto budet vypolneno v real'noj programme servera. Zamet'te, chto eto ne rabota s udp-osnovannymi uslugami. Naprimer, chtoby perenesti finger daemon, Vy dolzhny izmenit' corresponding liniyu v inetd.conf 1. Napisano Wietse Venema, wietse@wzv.win.tue.nl. # wrap finger daemon finger stream tcp nowait root /usr/sbin/tcpd in.fingerd Bez dobavleniya kakogo-libo access kontrolya, eto poyavitsya u klientu tochno takzhe kak i obychnaya ustanovka finger, za isklyucheniem togo, chto lyubye zaprosy budut registrirovat'sya k syslog's auth facility. Upravlenie dostupom vypolneno posredstvom dvuh fajlov, nazyvaemyh /etc/hosts.allow i /etc/hosts.deny. Oni soderzhat razreshenie vhodov i otricanie dostupa, sootvetstvenno, k nekotorym uslugam i hostam. Kogda tcpd obrabatyvaet pros'bu o obsluzhivanii finger ot klientskogo hosta, imenovannogo Biff.foobar.com, on prosmatrivaet hosts.allow i hosts.deny (v etom poryadke) dlya sootvetstvuyushchej zapisi i servisnogo i klientskogo hosta. Esli zapis' sootvetstviya byla najdena v - 168 - tsya, nezavisimo ot lyuboj zapisi v hosts.deny. Esli sootvetstvie najdeno v hosts.deny, to zapros budet otklonen zakryvaya svyaz'.shemu. Esli nikakoe sootvetstvie ne najdeno voobshche, zapros budet prinyat. Vhody v fajl dostupa vyglyadyat sleduyushchim obrazom: Servicelist: hostlist [: shellcmd] Servicelist - spisok servisnyh imen iz /etc/services, ili klyuchevoe slovo ALL. CHtoby sootvetstvovat' vsem uslugam za isklyucheniem finger i tftp, ispol'zujte "ALL"EXCGPT finger, tftp''. Hostlist - spisok imen hostov ili adresov IP, ili klyuchevyh slov ALL, LOCAL, ili UNKNOWN. ALL sootvetstvuet lyuboj host, v to vremya kak LOCAL sootvetstvuet imya hosta, ne soderzhashchie tochku.(2) UNKNOWN sootvetstvuet lyubym mnozhestvam ch'i nazvaniya ili adresa oshibochny. Name string, nachinayushcheesya s tochki sootvetstvuet vsem hostam, ch'i oblasti yavlyaetsya ravnymi etomu nazvaniyu. Naprimer,.foobar.com para - Biff.foobar.com. Imeyutsya takzhe usloviya dlya IP setevyh adresov i podset k stranice spravochnika (5) dlya detalej. Dlya togo, chtoby otkazat' v dostupe k finger i tftp uslugam, krome lokal'nyh hostov, pomestite sleduyushchee v /etc/hosts.deny, i sdelajte pustym /etc/hosts.allow: 2. Obychno tol'ko lokal'nye imena hostov, poluchennye iz poiskov v /etc/hosts ne soderzhat' nikakoj tochki. in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .your.domain Proizvol'naya shellcmd oblast' mozhet soderzhat' komandnuyu obolochku, chtobybyt' vyzvannoj, kogda zapis' soglasovana. |to polezno ustanovit' lovushku, kotoraya mozhet razoblachit' potencial'nyh napadavshih: in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \ echo "request from %d@%h" >> /var/log/finger.log; \ - 169 - if [ %h != "vlager.vbrew.com" ]; then \ finger -l @%h >> /var/log/finger.ly otlichny. Oblast' psevdonimov pozvolyaet tochno opredelit' al'ternativnye imena dlya togo zhe samogo obsluzhivaniya. Obychno, Vy ne dolzhny menyat' fajl uslug, kotoryj prihodit Naryadu s setevym programmnym obespecheniem na vashej Linux sisteme. Odnako, my daem maluyu vyborku iz togo fajla nizhe. # The services file: # # well-known services echo 7/tcp # Echo echo 7/udp # discard 9/tcp sink null # Discard discard 9/udp sink null # daytime 13/tcp # Daytime daytime 13/udp # chargen 19/tcp ttytst source # Character Generator chargen 19/udp ttytst source # ftp-data 20/tcp # File Transfer Protocol (Data) ftp 21/tcp # File Transfer Protocol (Control) telnet 23/tcp # Virtual Terminal Protocol smtp 25/tcp # Simple Mail Transfer Protocol nntp 119/tcp readnews # Network News Transfer Protocol # # UNIX services exec 512/tcp # BSD rexecd biff 512/udp comsat # mail notification login 513/tcp # remote login who 513/udp whod " # remote who and uptime shell 514/tcp cmd # remote command, no passwd used - 170 - syslog 514/udp # remote system logging printer 515/tcp spooler # remote print spooling route 520/udp router routed # routing information protocol Zamet'te, chto, naprimer, obsluzhivanie ECHO predlagaetsya na porte 7 dlya oboih i TCP i UDP, i etot port 512 ispol'zuetsya dlya dvuh razlichnyh uslug, a imenno dlya SISTEMY SPUTNIKOVOJ SVYAZI KOMSAT daemon (kotorye soobshchayut pol'zovatelyam otnositel'no novoj pochty, smotri xbiff(1x)), nad UDP, i dlya remote execution (rexec(1)), ispol'zuya TCP. # # Internet (IP) protocols # ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group multicast protocol tcp 6 TCP # transmission control protocol udp 17 UDP # user datagram protocol raw 255 RAW # RAW IP interface 10.4 Distancionnoe upravlenie Ochen' obshchij mehanizm dlya klient-servera prilozheniya obespechivaetsya RPC, paketom distancionnogo upravleniya. RPC byl razrabotan Sun Micrsystems, i eta sistema - nabor instrumental'nyh sredstv i bibliotechnyh funkcij. Vazhnye prilozheniya, sformirovanny na vershine RPC - NFS, Network Filesystem, i NIS, Network Information System, obe iz kotoryh budut predstavleny v sleduyushchih glavah. RPC server sostoit iz sistemy procedur togo, chto klient mozhet obratitsya, posylaya RPC zapros k serveru, naryadu s parametrami procedury. Server vyzovet oboznachennuyu proceduru po zashchite klienta, vruchaya obratno vozvrashchaemoe znachenie, esli imeetsya lyuboe. CHtoby byt' mashinno-nezavisimymi, zse zhannye, obmenennye mezhdu klientom i serverom - 171 - preobrazovanny k tak nazyvaemomu Vneshnemu Predstavleniyu Dannyh (XDR) otpravitelyu, i preobrazovanny obratno k mashinno - lokal'nomu Inogda, utochneniya k RPC prilozheniyu vvodyat nesovmestimye izmeneniya v procedure call interface. Konechno, pri prostom izmenenie server razrushil by vse prilozhenie, kotorye vse eshche ozhidayut original behavior. Sledovatel'no, RPC programmy imeyut nomera versii, pripisyvaemye k nim, obychno nachinayushchijsya s 1, i s kazhdoj novoj versiej RPC svyazhit s pomoshch'yu interfejsa etot schetchik. CHasto, server mozhet predlagat' neskol'ko versij odnovremenno; klientura zatem ukazyvaet nomerom versii versii oni hotyat ispol'zovat'. Setevaya svyaz' mezhdu RPC serverami i klienturoj - osobaya. RPC server predlagaet odin ili bolee sistemnyh procedur; kazhdoe mnozhestvo nazyvaetsya programmoj, i odnoznachno identificirovano nomerom programmy. Imena obsluzhivaniya otbora spiska sushchestvuyut dlya togo, chtoby zaprogrammirovat' chisla obychno sohranyaemye v /etc/rpc, vyborka kotorogo vosproizvedena nizhe ra risunke 10.4 V TCP/IP setyah, pered avtorami RPC stoyala zadacha programmirovaniya chisel k obobshchennym setevym uslugam. Oni vybrali - imet' kazhdyj server, obespechivayushchij, i TCP i UDP port dlya kazhdoj programmy i kazhdoj versii. Voobshche, RPC prilozheniya ispol'zuyut UDP posylku dannyh, i vozvrashchayutsya obratno k TCP togda, kogda dannye, kotorye budut peredany ne vpishutsya v edinstvennuyu UDP datagrammu. Konechno, klientskie programmy dolzhny imet' sposob vyyasnit' kotoryj iz nih port otobrazheniya nomera programmy. Ispol'zovanie fajla konfiguracii dlya etogo, byl by slishkom negibki; s teh por RPC prilozheniya ne ispol'zuyut zarezervirovannye porty, ne imeetsya nikakoj garantii, chto port pervonachal'no podrazumeval ispol'zovat'sya nashe prilozhepie "baz dannyh. Sledovatel'no, RPC prilozheniya vybirayut lyuboj port kotoryj, oni mogut poluchit', i zaregistrirovat' eto s tak nazyvaemym por dejstviya - kak obsluzhivanie broker dlya vseh RPC serverov, vypolnyayushchiesya na mashine: klient, kotoryj hochet vojti v kontakt s obsluzhivaniem s dannym nomerom programmy snachala sdelaet zapros - 172 - portmapper na chisla porta obsluzhivanie, kotorye mogut byt' dostignuty. |tot metod imeet chastichnyj nedostatok, chto eto vvodit edinstvennuyu tochku otkaza, ochen' pohozhuyu na inetd daemon. Odnako, etot sluchaj nemnogo huzhe, potomu chto kogda portmapper umiraet, vsya RPC informaciya porta teryaetsya; eto obychno znachit, chto Vy dolzhny perezapustit' vse RPC servery vruchnuyu, ili perezagruzit' celuyu mashinu. Na Linux, portmapper nazyvaetsya rpc.portmap i postoyanno nahoditsya v /usr/sbin. Krome uvereniya togo, chto eto nachato iz rc.inet2, rortmapper ne trebuet lyuboj raboty po konfiguracii. 10.5 Konfigurirovanie r komand Imeetsya ryad komand dlya vypolneniya komand na remote hoste. Oni - rlogin, rsh, rcp i rcmd. Oni vse porozhdayut obolochku na remote hoste i pozvolyayut pol'zovatelyu vypolnyat' komandy. Konechno, klient dolzhen imet' account na hoste, gde komanda dolzhna byt' vypolnena. Takim obrazom vse eti komandy vypolnyayut proceduru razresheniya. Obychno, klient soobshchyaet nazvanie vhoda v sistemu pol'zovatelya na server, kotoryj # # /etc/rpc - miscellaenous RPC-based services # portmapper 100000 portmap sunrpc rstatd 100001 rstat rstat svc rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog ypserv 100004 ypprog mountd 100005 mount showmount ypbind 100007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd bootparam 100026 " ypupdated 100028 ypupdate - 173 - Ris. 16. A sample /etc/rpc file. po ocheredi zaprashivaet parol', kotoryj utverzhden obychnym sposobom. Inogda, odnako, zhelatel'no oslabit' proverki razresheniya dlya nekotoryh pol'zovatelej. Naprimer, esli Vy chasto dolzhny registrirovat'sya v drugih mashinah na vashej lokal'noj vychislitel'noj seti, Vy mogli by zahotet' byt' priznannym bez vvoda parolya kazhdyj raz. Otklyuchenie razresheniya zhelatel'no tol'ko na malom chisle hostov, ch'i bazy dannyh parolej sinhronizirovany, ili dlya malogo chisla iz privilegirovannyh pol'zovatelej, kotorye dolzhny obrashchat'sya k mnogim mashinam dlya administrativnoj prichiny. Vsyakij raz, kogda Vy hotite pozvolyat' lyudyam regestrirovat'sya na vashem hoste pri neobhodimosti tochno opredelit' identichnost' vhoda v sistemu ili parol', udostoverites', chto Vy ne delaete oshibku predostavlyaya dostup komu-nibud' eshche. Imeyutsya dva sposoba blokirovat' razreshenie, dlya togo chtoby proverit' r komandy. Kazhdyj - dlya super pol'zovatelya, chtoby pozvolit' nekotorym ili vsem pol'zovatelyam zaregestrirovat'sya bez parolya. |tot dostup upravlyaetsya kartotekoj vyzyvaemoj /etc/hosts.equiv. |to soderzhit spisok mnozhestv i imen pol'zovatelya, kotorye rassmatrivayutsya ekvivalentnymi pol'zovatelyam na lokal'nom hoste. Al'ternativnaya opciya - dlya pol'zovatelya - predostavlenie drugim pol'zovatelyam na nekotoryh h byt' perechisleny v fajle.rhosts v direktorii pol'zovatelya. Dlya soobrazhenij bezopasnosti, eta kartoteka dolzhna prinadlezhat' pol'zovatelyu ili super pol'zovatelyu, i ne dolzhna byt' symbolic link, inache eto budet ignorirovan Kogda klient zaprashivaet r obsluzhivanie, ee host i nazvanie pol'zovatelya ishchyutsya v fajle /etc/hosts.equiv, i zatem v fajle.rhosts pol'zovatelya. Kak - primer, predpolozhim, chto janet rabotaet " gausse i pytaetsya zaregestrirovat'sya v joe's account na euler. Sleduya dalee, my obratimsya k Janet kak klientskomu pol'zovatelyu, i k Joe kak k Lokal'nomu pol'zovatelyu. - 174 - Teper', kogda tipy Janet $ Rlogin -l joe euler na gausse, server snachala proveril by hosts.equiv (4), predostavlen li Janet svobodnyj dostup, i esli net, to on poprobuet prosmotret'.Rhosts v ishodnom kataloge joe's. Fajl hosts.equiv na euler pohodit na eto: gauss euler -public quark.physics.groucho.edu andres Zapis' sostoit iz nazvaniya hosta, neobyazatel'no soprovozhdaemogo imenem pol'zovatelem. Esli nazvanie mnozhestva poyavlyaetsya vezde, to vse pol'zovateli ot togo mnozhestva budut dopushcheny k ih lokal'nym acount bez lyubyh proverok. V vysheizlozhennom primere, Janet pozvolili by zaregestrirovat'sya v ee account janet kogda vyhodit iz gaussa, i tot zhe samyj primenyaetsya lyubomu drugomu pol'zovatelyu za isklyucheniem root Odnako, esli Janet zahochet zaregestrirovat'sya kak joe , parolya kak obychno. Esli nazvanie hosta soprovozhdaetsya nazvaniem pol'zovatelya, kak i v poslednej linii vysheupomyanutoj tipovoj kartoteki, to etomu pol'zovatelyu budet dan parol'-svobodnyj dostup ko vsem accont za isklyucheniem accony\t root. Imeni hosta mozhet takzhe predshestvovat' znak "minus", kak na zapisi "-obshchij". |to trebuet razresheniya na vse account na obshchem, nezavisimo ot togo, chto pol'zovateli edinichnogo prava predostavlyayut v ih kartoteke.rhosts. 3. V NFS srede okruzheniya, Vy byli by dolzhny dat' etomu zashchitu 444, potomu chto super pol'zovatel' chasto ogranichivaet v dostupe k fajlam na diskah, ustanovlennyh cherez NFS. 4. Zametit', chto fajl hosts.equiv ne obyskan kogda kto -to delaet popytku k registracii kak root. - 175 - " / 165 - Formatfajla.rhosts identichen takovomu hosts.equiv, no znachenie nemnogo otlichno. Rassmotrite Joe's.rhosts fajl na Euler: chomp.cs.groucho.edu gauss janet Pervaya zapis' dopuskaet, chto joe osvobozhdayut acess pri registracii iz Chomp.cs.groucho.edu, no ne vozdejstvuyut na prava lyubogo drugogo account na euler ili chomp. Vtoraya zapis' - nebol'shoe izmenenie etogo, v kotorom predostavlyaetsya janet svobodnyj dostup k account Joe pri registracii iz gaussa. Zamet'te, chto nazvanie hosta klienta polucheno obratnym otborom. Adres vyzyvayushchego operatora k nazvaniyu, tak, chtoby eta osobennost' failed s hostami k reshayushchemu ustrojstvu. Imya hosta klienta rassmatrivaetsya v sootvetstvii s nazvanim v hostah zaregistri rovannyh v odnom iz sleduyushchih sluchaev: + Kanonicheskioe imya hosta klienta (ne psevdonim) bukval'no sootvetstvuet imeni hosta v fajle. + Esli imya hosta klienta - polnost'yu kvalificirovanno, to nazvanie oblasti (tipa vozvrashchennogo reshayushchim ustrojstvom, kogda Vy imeete vypolnyayushchuyu DNS), ne sootvetstvuet imeni hosta v mnozhestvah fajlov, eto sravnivaetsya s tem imenem hosta, rasshirennym s lokal'nym nazvaniem oblasti. 11. Setevaya informacionnaya sistema Kogda Vy zapuskaete lokal'nuyu vychislitel'nuyu set', vasha cel' - obespechit' sredu okruzheniya vashim pol'zovatelyam, kotoraya delaet set' ochevidnoj. Vazhen stepping stone k etomu koncu dolzhen hranit' nasushchnymi dannye tipa pol'zovatelya sinhronizirovannye mezhdu vsemi - 176 - mnozhestvami. My videli pered etim, chto dlya resheniyaimeni hosta, moshchnoe i slozhnoe obsluzhivanie sushchestvuet, yavlyayushcheesya DNS. Dl