Tcpdump - Linux Command - Unix հրամանատարությունը

ԱՆՈՒՆ

tcpdump - ցանցում ցանցի տրաֆիկ

SYNOPSIS- ը

tcpdump [ -adeflnNOpqRStuvxX ] [ -c count ]

[ -C file_size ] [ -F ֆայլ ]

[ -i ինտերֆեյս ] [ -m մոդուլ ] [ -r ֆայլ ]

[ -s snaplen ] [ -T տեսակ ] [ -U օգտվողի ] [ -w ֆայլ ]

[ -A algo: գաղտնիք ] [ արտահայտություն ]

DESCRIPTION

Tcpdump- ը տպում է փաթեթների վերնագրեր ցանցային ինտերֆեյսի վրա, որը համապատասխանում է բուլյան արտահայտությանը : Այն կարող է նաեւ գործարկվել -w դրոշի հետ, որը հանգեցնում է այն փրկել փաթեթին տվյալների հետագա վերլուծության համար եւ / կամ -r դրոշի հետ, որը հանգեցնում է այն կարդալ փրկված փաթեթի ֆայլից, այլ ոչ թե կարդալ փաթեթներ ցանցի ինտերֆեյսից: Բոլոր դեպքերում, միայն փաթեթները, որոնք համապատասխանում են արտահայտությանը , կվերանվանվեն tcpdump- ով :

Tcpdump- ը, եթե չլցվի -c դրոշի հետ, շարունակում է գրավել փաթեթները, մինչեւ այն ընդհատվում է SIGINT ազդանշանով (գեներացվել է, օրինակ `ձեր ընդհատման բնույթը, սովորաբար Control-C) կամ SIGTERM ազդանշան (սովորաբար գեներացվել է սպանությունը (1) հրաման); եթե գործարկվի -c դրոշով, այն գրավում է փաթեթներ, մինչեւ այն ընդհատվում է SIGINT կամ SIGTERM ազդանշանի կողմից կամ նշված փաթեթների քանակը մշակվել է:

Երբ tcpdump- ը ավարտում է փաթեթները գրավելը, այն կներկայացնի հաշիվներ.

«ֆիլտրով ստացված» փաթեթները (այս իմաստը կախված է այն OS- ից, որի վրա աշխատում եք tcpdump եւ հնարավոր է, որ OS- ն կազմաձեւվի, եթե հրամանի տողում նշված է զտիչ, որոշ օպերացիաներում այն ​​ակնկալում է փաթեթներից անկախ անկախ այն բանից, թե արդյոք դրանք համապատասխանում են ֆիլտրի արտահայտությանը, եւ մյուս օպերացիաներում այն ​​համարում է միայն փաթեթներ, որոնք համապատասխանում են ֆիլտրի արտահայտությանը եւ մշակվում են tcpdump- ով );

(այսինքն ` բեռնաթափման տարածքների բացակայության պատճառով), այն դեպքում, երբ OS- ն հայտարարում է, որ տեղեկատվությունը դիմում է, եթե ոչ, ապա այն կհայտարարվի որպես 0):

SIGINFO- ի ազդանշանին աջակցող հարթակների վրա, օրինակ, BSD- ի մեծ մասը, այն կներկայացնի այն հաշիվները, երբ այն ստանում է SIGINFO ազդանշան (գեներացվել է, օրինակ, ձեր `` կարգավիճակը '' տիպը, սովորաբար, վերահսկելու-T) եւ կշարունակեն գրավել փաթեթները .

Ցանցի ինտերֆեյսից ընթերցման փաթեթները կարող են պահանջել, որ դուք ունեք հատուկ արտոնություններ:

SunOS 3.x կամ 4.x- ի ներքո NIT կամ BPF:

Դուք պետք է ընթերցեք ընթերցել / dev / nit կամ / dev / bpf * :

Solaris տակ DLPI:

Դուք պետք է կարդաք / գրեք մուտք դեպի ցանցային կեղծ սարքի, օրինակ, / dev / le : Առնվազն որոշ Solaris տարբերակները, սակայն, դա բավարար չէ, որպեսզի tcpdump- ը թույլ տա խուսափել ռեժիմում: Solaris- ի այդ տարբերակներում դուք պետք է արմատ ունենաք , կամ tcpdump- ը պետք է տեղադրվի setuid արմատից, որպեսզի չխոչընդոտեք գաղտնի ռեժիմում: Նշենք, որ բազմաթիվ (թերեւս բոլոր) ինտերֆեյսների վրա, եթե դուք չեք տիրապետում խտրական ռեժիմում, չեք տեսնում որեւէ ելքային փաթեթ, այնպես որ գաղտնի ռեժիմում չկատարված գրավումը չի կարող օգտակար լինել:

HP-UX- ի ներքո DLPI- ով:

Դուք պետք է արմատ ունենաք կամ tcpdump- ը տեղադրվի setuid- ի արմատից:

IRIX- ի ներքո snoop- ով:

Դուք պետք է արմատ ունենաք կամ tcpdump- ը տեղադրվի setuid- ի արմատից:

Linux- ում:

Դուք պետք է արմատ ունենաք կամ tcpdump- ը տեղադրվի setuid- ի արմատից:

Ուլտրիկս եւ թվային UNIX / Tru64 տակ UNIX:

Ցանկացած օգտվող կարող է գրավել ցանցի երթեւեկությունը tcpdump- ով : Այնուամենայնիվ, ոչ մի օգտվող (նույնիսկ նույնիսկ գերծանրքաշային օգտագործող) չի կարող ինտերֆեյսի վրա խառնաշփոթ ռեժիմում գրավել, եթե սուպեր-օգտագործողը թույլ չտա այդ ինտերֆեյսում խառնաշփոթի ռեժիմ գործել, օգտագործելով pfconfig (8), եւ ոչ մի օգտվող (նույնիսկ նույնիսկ սուպեր- ) կարող է գրավել միացատկային երթեւեկությունը, որը ստացել կամ ուղարկվել է մեքենայի կողմից ինտերֆեյսի վրա, եթե սուպեր-օգտագործողը հնարավորություն տա pfconfig- ի օգտագործմամբ այդ ինտերֆեյսի պատճեն-բոլոր ռեժիմում գործողությունը, այնպես որ ինտերֆեյսի վրա օգտակար փաթեթների հավաքագրումը, հավանաբար, պահանջում է, թե ոչ խայտառակ ռեժիմ կամ պատճեն -Բոլոր ռեժիմի շահագործումը կամ գործողությունների երկու եղանակները, այդ ինտերֆեյսի վրա միացված լինեն:

BSD- ի տակ.

Դուք պետք է ընթերցեք ընթերցել / dev / bpf * :

Պահված փաթեթի ֆայլի ընթերցումը չի պահանջում հատուկ արտոնություններ:

ԸՆՏՐՈՒԹՅՈՒՆՆԵՐԸ

-ա

Փորձեք ցանցի փոխանակման եւ հասցեների անուններ փոխանցել:

-կ

Հաշվի փաթեթներ ստանալուց հետո ելք:

-Ք

Նախքան հումքային փաթեթը փրկության ֆայլ գրելիս ստուգեք, արդյոք ֆայլը ներկայումս file_size- ից ավելի մեծ է, եւ եթե այդպես է, փակեք ընթացիկ savefile- ը եւ բացեք նորը: Savefiles- ը առաջին savefile- ից հետո կունենա անուն, որը նշվում է -w դրոշի ներքո, հետո մի շարք, սկսած 2-ից եւ շարունակում է շարունակել: File_size- ի միավորները միլիոնավոր բայ են (1,000,000 բայտ, ոչ 1,048,576 բայթ):

-դ

Թափահարված փաթեթի համընկնող կոդը կոտրել մարդկային ընթերցման ձեւով ստանդարտ թողարկման եւ դադարեցնել:

-համ

Փաթեթի համընկնող կոդը կոճակ, որպես C ծրագիր:

-դդ

Փաթեթի համընկնող կոդը որպես տասնորդական թվեր (նախորդում է հաշվարկի):

-հ

Տպագիր մակարդակի վերնագիրն ամեն աղբանոցի գիծում տպեք:

-Ե

Օգտագործեք ալգո. Գաղտնիք IPsec ESP փաթեթների ապակոդավորման համար: Ալգորիթմները կարող են լինել des-cbc , 3des-cbc , blowfish-cbc , rc3-cbc , cast128-cbc կամ ոչ մեկը : Սխալը des-cbc- ն է : Փաթեթների վերծանման ունակությունը միայն ներկա է, եթե tcpdump- ը կազմված է գաղտնագրման հնարավորությունով: գաղտնի էստիցի տեքստը ESP- ի գաղտնի բանալու համար: Այս պահի դրությամբ մենք չենք կարող դիմանալ երկակի արժեք ունենալ: Ընտրանքը ենթադրում է RFC2406 ESP, այլ ոչ թե RFC1827 ESP: Տարբերակը միայն կարգաբերման նպատակով է, եւ հուսով է, որ այս տարբերակի օգտագործումը իսկապես «գաղտնի» բանալին է: Ներկայացնելով IPsec գաղտնի բանալին հրամանի տողի վրա, այն ձեզ դարձնում է տեսանելի դարձնում ps (1) եւ այլ առիթներով:

-ֆ

Տպել `օտարերկրյա ինտերնետային հասցեները, ոչ թե խորհրդանշականորեն, այլ թվային (այս տարբերակը նախատեսված է Sun- ի yp սերվերի լուրջ ուղեղի վնասվածքի մասին, սովորաբար այն կախված է անընդմեջ տեղական ինտերնետի համարներից):

-Ֆ

Օգտագործեք ֆայլը, որպես ֆիլտրի արտահայտության մուտքագրման համար: Հրամանի տողում տրված լրացուցիչ արտահայտությունը անտեսվում է:

-i

Լսեք ինտերֆեյսի վրա : Եթե ​​անհայտ է, tcpdump- ը որոնում է համակարգի ինտերֆեյսների ցանկը ամենացածր համարակալված, կազմաձեւված ինտերֆեյսի համար (բացառությամբ loopback): Կապերը կոտրված են `ընտրելով ամենավաղ խաղը:

Linux համակարգերում, 2.2 կամ ավելի ուշ միջերեսներ , կարող են օգտագործվել ինտերֆեյսի ցանկացած « ինտերֆեյս» փաստարկ `բոլոր ինտերֆեյսներից փաթեթներ հավաքելու համար: Նշենք, որ «ցանկացած» սարքի գրավումը չի կատարվի խայտառակ ռեժիմում:

-լ

Կատարել stdout գիծը buffered: Օգտակար, եթե դուք ցանկանում եք տեսնել տվյալների հավաքագրման ժամանակ: Օրինակ,
`` tcpdump -l | թե `tcpdump -l> dat & pail -f dat '' - ը:

-մ

Բեռնել SMI MIB մոդուլի սահմանումները ֆայլային մոդուլից : Այս տարբերակը կարող է օգտագործվել մի քանի անգամ, որպեսզի մի քանի MIB մոդուլներ բեռնեք tcpdump- ում :

-Ն

Չեն փոխարկել հյուրընկալող հասցեները անուններով: Դա կարող է օգտագործվել DNS- ի կանխարգելումից խուսափելու համար:

-հ

Չեն փոխակերպել արձանագրությունները եւ պորտային համարները եւ այլն:

-Ն

Մի տպեք հոսթին անունների դոմենի որակավորում: Օրինակ, եթե դուք դրեք այս դրոշը, ապա tcpdump- ը տպելու է `` nic.ddn.mil '' փոխարեն `` `nic '':

-Ո

Մի փաթեթի համապատասխանող կոդերի օպտիմալացման համակարգը չի գործում: Սա օգտակար է միայն այն դեպքում, եթե դուք կասկածում եք, որ սխալ է optimizer- ում:

-պ

Ինտերֆեյսը խանգարող ռեժիմի մեջ մի դրեք: Նշենք, որ ինտերֆեյսը կարող է լինել այլընտրանքային եղանակով: հետեւաբար, «-p» - ը չի կարող օգտագործվել որպես «Ether host» - ի {local-hw-addr} կամ եթերային հեռարձակման համար հապավումը:

-գ

Արագ (հանգիստ) արտադրանք: Տպեք քիչ արձանագրություն տեղեկություն, այնպես որ արտադրանքի գծերը ավելի կարճ են:

-Ռ

Ենթադրենք, ESP / AH փաթեթները հիմնված են հին հստակության վրա (RFC1825-ից RFC1829): Եթե ​​նշված է, tcpdump- ը չի տպագրում replay կանխարգելման դաշտ: Քանի որ ESP / AH հստակեցման մեջ չկա արձանագրության տարբերակ դաշտ, tcpdump- ը չի կարող հանել ESP / AH արձանագրության տարբերակը:

-ռ

Կարդացեք փաթեթներից ֆայլից (որը ստեղծված է -w տարբերակի հետ): Ստանդարտ մուտքագրումը օգտագործվում է, եթե ֆայլը `` `- ':

-Ս

Տպեք բացարձակ, ոչ թե համեմատական, TCP հաջորդականության համարները:

-ս

Snarf- ը յուրաքանչյուր փաթեթից ստացված տվյալների բայթն է, այլ ոչ թե 68-ի լկտի (SunOS- ի NIT- ի հետ, նվազագույնը, փաստորեն, 96): 68 բայթ համարժեք է IP- ի, ICMP- ի, TCP- ի եւ UDP- ի համար, սակայն կարող է կրճատել արձանագրային տեղեկությունները անուն սերվերի եւ NFS փաթեթներից (տես ստորեւ): Փաթեթները, որոնք սահմանափակվում են սահմանափակ պատկերով, նշված են `` [| proto ] ', որտեղ proto- ն արձանագրության մակարդակի անունն է, որի ժամանակ կրճատումը տեղի է ունեցել: Նշենք, որ ավելի մեծ կրկնօրինակներ ստանալը մեծացնում է փաթեթի մշակման ժամանակը եւ արդյունավետ կերպով նվազեցնում է փաթեթի բուֆերային արժեքը: Սա կարող է հանգեցնել փաթեթների կորստի: Դուք պետք է սահմանափակեք snaplen- ին ամենափոքր թվաքանակը, որը գրավելով ձեր արձանագրած տեղեկությունները: 0-ի փոխարինումը նշանակում է օգտագործեք պահանջվող երկարությունը, բռնելու ամբողջական փաթեթներ:

-Թ

Force փաթեթը, որը ընտրված է « արտահայտությամբ », պետք է մեկնաբանվի տվյալ տեսակի համար : Ներկայումս հայտնի տեսակներ են cnfp (Cisco NetFlow արձանագրությունը), rpc (Remote Procedure Call), rtp (Real-Time Applications արձանագրություն), rtcp (իրական ժամանակի կիրառման հսկողության արձանագրությունը), snmp (Simple Network Management Protocol), vat (Visual Audio Tool ) եւ wb (բաշխված Սպիտակ խորհուրդը):

-թ

Մի թողեք ժամանակի նշագիծ յուրաքանչյուր վերամշակման գոտում:

-թթ

Տպեք անջատված ժամանակային նշան յուրաքանչյուր աղբանոցում:

-U

Կաթիլային արտոնություններն անկում են ապրում եւ փոխում օգտվողի ID- ն օգտվողի եւ խմբի ID- ի օգտագործողի հիմնական խմբին:

Նշում! Red Hat Linux- ը ավտոմատ կերպով դադարեցնում է «pcap» օգտագործողի արտոնությունները, եթե այլ բան նախատեսված չէ:

-թթ

Տպեք մի դելտայի (միկրո-վայրկյանում) ընթացիկ եւ նախորդ գծի միջեւ, յուրաքանչյուր վերամշակման գծի վրա:

-tttt

Տպագրեք ժամանակային նշան, ըստ ստանդարտ ձեւաչափի, յուրաքանչյուր անցակետի ամսաթվով:

-u

Տպել undecoded NFS բռնակներ:

-վ

(Մի փոքր ավելի) մանրամասն արդյունք: Օրինակ, IP փաթեթում ապրելու, նույնականացման, ընդհանուր երկարության եւ ընտրանքների ժամանակն է տպագրվում: Նաեւ հնարավորություն է ընձեռում լրացուցիչ փաթեթի ամբողջականության ստուգումներ, ինչպիսիք են IP- ի եւ ICMP- ի ղեկավարության ստուգումների ստուգումը:

-vv

Նույնիսկ ավելի բարդ արդյունք: Օրինակ, լրացուցիչ դաշտերը տպագրվում են NFS պատասխանատու փաթեթներից, եւ SMB փաթեթները լիովին վերծանվում են:

-վվ

Նույնիսկ ավելի բարդ արդյունք: Օրինակ, telnet SB ... SE տարբերակները տպագրվում են ամբողջությամբ: With -X telnet- ի տարբերակները տպագրվում են նաեւ hex- ում:

-վ

Գրեք հումքի փաթեթները, այլ ոչ թե վերլուծելու եւ տպագրելու համար: Նրանք կարող են հետագայում տպել -r տարբերակով: Ստանդարտ արտադրանքը օգտագործվում է, եթե ֆայլը `` `` `:

-խ

Տպեք յուրաքանչյուր փաթեթ (մինուս կապի մակարդակի վերնագիր), տասնութ: Փաթեթի փոքրիկ մասը կամ շտապ բլթերը տպագրվելու են: Նշենք, որ սա ամբողջ հղիչի շերտային փաթեթն է, ուստի այն շերտերի համար, ինչպիսիք են պահոցը (օրինակ, Ethernet), padding բայթը նույնպես տպագրվելու է, երբ ավելի բարձր շերտանոց փաթեթը կարճ է, քան պահանջվող լիցքավորումը:

-X

Երբ տպագրելով hex, տպեք ascii էլ: Այսպիսով, եթե -X- ը նույնպես սահմանվում է, փաթեթը տպագրվում է hex / ascii- ում: Սա շատ հարմար է նոր արձանագրությունների վերլուծության համար: Նույնիսկ եթե -x- ը չի սահմանվել, որոշ փաթեթների որոշ մասեր կարող են տպագրվել hex / ascii- ում:

արտահայտությունը

ընտրում է, թե ինչ փաթեթներ կհանվեն: Եթե ​​որեւէ արտահայտություն չի տրվում, զուտ բոլոր փաթեթները կվերացվեն: Հակառակ դեպքում, միայն փաթեթները, որոնց համար արտահայտությունը «ճշմարիտ է», կհեռացվի:

Արտահայտությունը բաղկացած է մեկ կամ ավելի պրիմիտիվներից: Պրիմիտիվները սովորաբար բաղկացած են id (անուն կամ համար), որը նախորդում է մեկ կամ ավելի ընտրողների կողմից: Կան երեք տարբեր տեսակի որակավորում:

տիպ

որակավորողները ասում են, թե ինչպիսին է id անունը կամ համարը: Հնարավոր տիպերը հյուրընկալող , զուտ եւ նավահանգիստ : Օրինակ, «հյուրընկալող», «զուտ 128.3», «պորտ 20»: Եթե ​​չկա տեսակի որակավորում, ստացվում է հյուրընկալողը :

dir

որակավորողները նշում են որոշակի փոխանցման ուղղություն եւ / կամ id : Հնարավոր ուղղությունները src , dst , src կամ dst եւ src եւ dst : Օրինակ, `src foo ',' dst net 128.3 ',' src կամ dst port ftp-data ': Եթե ​​գոյություն չունենա դասակարգիչ, ապա ստացվում է src կամ dst : «Null» հղման շերտերի համար (այսինքն, կետի կետերի արձանագրությունները, ինչպիսիք են սայթը), ներգնա եւ ելքային ընտրողները կարող են օգտագործվել ցանկալի ուղղություն սահմանելու համար:

պրոտո

որակավորումները սահմանափակում են խաղը որոշակի արձանագրության մեջ: Հնարավոր պրոտոները հետեւյալն են ` եթեր , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp եւ udp : Օրինակ `« Eher src foo »,« arp net 128.3 »,« tcp port 21 ': Եթե ​​չկա պրոտո որակավորում, ենթադրվում է, որ բոլոր արձանագրությունները համապատասխանում են այդ տիպին: Օրինակ `« սփռոց »նշանակում է` (ip կամ arp կամ rarp) src foo (բացառությամբ վերջինս իրավական սինտեխնոլոգիա չէ), «զուտ բար» նշանակում է `(ip կամ arp կամ rarp) զուտ բար» եւ «նավահանգիստ 53» `(tcp կամ udp) նավահանգիստ 53 ':

[`` fddi` իրականում այլ է `էթերի համար '; parser- ը նույնն է վերաբերվում նրանց, որպես իմաստ `` տվյալ ցանցի ինտերֆեյսի վրա օգտագործված տվյալների շփման մակարդակը: 'FDDI- ի վերնագրերը պարունակում են Ethernet- ի նման աղբյուր եւ հասցեի հասցեներ եւ հաճախ պարունակում են Ethernet նման փաթեթի տեսակներ, այնպես որ կարող եք զտել այս FDDI դաշտերը ինչպես նույնական Ethernet դաշտերը: FDDI վերնագրերը նաեւ պարունակում են այլ դաշտեր, բայց դուք չեք կարող դրանք բացահայտորեն արտահայտել ֆիլտրի արտահայտության մեջ:

Նմանապես, «tr» - ը, «ether» - ի համար: նախորդ պարբերության FDDI վերնագրերի վերաբերյալ հայտարարությունները վերաբերում են նաեւ Token Ring- ի վերնագրերին:]

Բացի վերը նշվածից, գոյություն ունեն հատուկ «պարզունակ» բառեր, որոնք չեն հետեւում օրինակին ` դարպաս , հեռարձակում , պակաս , ավելի մեծ եւ թվաբանական արտահայտություններ: Բոլորը նկարագրված են ստորեւ:

Ավելի բարդ ֆիլտրի արտահայտություններ են կառուցված, օգտագործելով բառերը եւ , եւ ոչ թե համատեղել primitives. Օրինակ `« հյուրընկալող սերվեր », եւ ոչ թե նավահանգիստ FTP, եւ ոչ թե նավահանգիստ ftp-data»: Փրկել տեքստը, նույնական ընտրացուցակները կարող են բաց թողնել: Օրինակ `tcp dst port ftp կամ ftp-data կամ տիրույթը նույնն է, ինչ` tcp dst port ftp կամ tcp dst port ftp-data կամ tcp dst port տիրույթը:

Թույլատրելի primitives են:

dst հյուրընկալող սերվեր

Ճիշտ է, եթե փաթեթի IPv4 / v6 նշանակման դաշտը հյուրընկալող է , որը կարող է լինել էլեկտրոնային հասցե կամ անուն:

src հյուրընկալող սերվեր

Ճիշտ է, եթե փաթեթի IPv4 / v6 աղբյուրը հյուրընկալում է :

հյուրընկալող հյուրը

Ճիշտ է, եթե փաթեթի IPv4 / v6 աղբյուրը կամ ուղղությունը տեղակայված է: Վերոհիշյալ հյուրընկալող արտահայտություններից որեւէ մեկը կարող է առաջ ընթանալ հիմնաբառերով, ip- ում , arp- ում , rarp- ում կամ ip6- ում, ինչպես նաեւ.

ip հյուրընկալող հյուրընկալող

ինչը համարժեք է.

Ether proto \ ip եւ հյուրընկալող սերվեր

Եթե հյուրընկալողը բազմակի IP հասցեներով անուն է, յուրաքանչյուր հասցեն ստուգվում է խաղի համար:

Eher dst ehost

Ճիշտ է, եթե Ethernet նպատակակետի հասցեն էլ ուրվական է : Ehost- ը կարող է կամ / etc / eters- ից կամ անունից անուն լինել (թվային ձեւաչափի համար տես էթերը (3N)):

Ether src ehost

Ճիշտ է, եթե Ethernet աղբյուրի հասցեն էլ ուրվական է :

Էթերի հյուրընկալող ուրվականը

Ճիշտ է, եթե կամ Ethernet աղբյուրը կամ հասցեի հասցեն ուրվական է :

դարպասի հյուրատուն

Ճիշտ է, եթե փաթեթը օգտագործողն օգտագործեց որպես դարպաս: Այսինքն, Ethernet- ի աղբյուրը կամ հասցեի հասցեը հյուրընկալվել էր, բայց ոչ IP- ի աղբյուրը, ոչ էլ IP- ի նպատակակետը չէր ընդունվում : Host- ը պետք է լինի անուն եւ պետք է գտնվի ինչպես մեքենայի հյուրընկալող անունի IP- հասցեի լուծման մեխանիզմների (սերվերի անվան ֆայլ, DNS, NIS, եւ այլն), այնպես էլ մեքենայի host-name- ից Ethernet-address resolution մեխանիզմ (/ etc / eters եւ այլն): (Համարժեք արտահայտություն է

Ether հյուրընկալող ուրվականը եւ հյուրընկալող հյուրը

որը կարող է օգտագործվել host / ehost- ի անուններով կամ թվերով:) Այս շարքը այս պահին չի աշխատում IPv6- ի կողմից թույլատրված կազմաձեւում:

dst net net

Ճիշտ է, եթե փաթեթի IPv4 / v6 հասցեի հասցեն ունի ցանցի ցանց : Զուտը կարող է լինել / etc / ցանցերի կամ ցանցի համարից անունը (տես մանրամասների համար ցանցերը (4) ):

src net net

Ճիշտ է, եթե փաթեթի IPv4 / v6 աղբյուրը ցանցի ցանցի ցանցն ունի:

զուտ ցանց

Ճիշտ է, եթե փաթեթի IPv4 / v6 աղբյուրը կամ նշանակման հասցեն ունի ցանցի ցանցի համարը:

net net mask netmask

Ճիշտ է, եթե IP- հասցեն համապատասխանում է զուտ ցանցային ցանցին : Կարող է որակվել src կամ dst : Նշենք, որ այս շարադրանքը IPv6 ցանցի համար վավեր չէ:

զուտ ցանց / լեն

Ճիշտ է, եթե IPv4 / v6 հասցեն համընկնում է զուտ ցանցի մկների լայնության հետ: Կարող է որակվել src կամ dst :

dst port port

Ճիշտ է, եթե փաթեթը ip / tcp, ip / udp, ip6 / tcp կամ ip6 / udp, եւ ունի նավահանգստի նշանակման նավահանգիստ արժեք: Պորտը կարող է լինել մի շարք կամ անուն, որը օգտագործվում է / etc / services- ում (տես tcp (4P) եւ udp (4P)): Եթե ​​անունը օգտագործվում է, ստուգվում են եւ նավահանգստի համարը եւ արձանագրությունը: Եթե ​​օգտագործվում է մի շարք կամ ոչ երկիմաստ անուն, ստուգվում է միայն նավահանգստի համարը (օրինակ, dst port 513- ը տպում է թե tcp / մուտքի երթեւեկությունը եւ udp / ով երթեւեկությունը, եւ պորտային տիրույթը տպելու է թե 'tcp / domain եւ udp / domain տրաֆիկ):

src պորտի նավահանգիստ

Ճիշտ է, եթե փաթեթը ունի պորտի աղբյուրի նավահանգիստ արժեք:

նավահանգիստ նավահանգիստ

Ճիշտ է, եթե փաթեթի աղբյուրը կամ նավահանգիստը նավահանգիստ է : Յուրաքանչյուր վերը նշված պորտի արտահայտությունների համար կարող է առաջադրվել հիմնաբառեր, tcp կամ udp , ինչպես նաեւ `

tcp src պորտ պորտը

որը համապատասխանում է միայն tcp փաթեթներ, որոնց աղբյուրը նավահանգիստ է:

պակաս երկարություն

Ճիշտ է, եթե փաթեթը երկարություն ունի կամ ավելի երկար է : Սա համարժեք է.

len <= երկարություն :

ավելի մեծ երկարություն

Ճիշտ է, եթե փաթեթն ունի երկարություն ավելի մեծ կամ հավասար երկարությամբ : Սա համարժեք է.

len> = երկարություն :

ip proto արձանագրությունը

Ճիշտ է, եթե փաթեթը IP փաթեթ է (տես ip (4P)) արձանագրության տիպի արձանագրություն : Արձանագրությունը կարող է լինել icmp , icmp6 , igmp , igrp , pim , ah , esp , vrrp , udp կամ tcp անունների թվերից կամ մեկը: Նշենք, որ identcers tcp , udp եւ icmp են նաեւ հիմնաբառեր եւ պետք է փախչել միջոցով ճառագայթման (\), որը \\ է C- shell. Նշենք, որ այս պարզունակ չի հալածում արձանագրության շերտի շղթան:

ip6 proto արձանագրություն

Ճիշտ է, եթե փաթեթը հանդիսանում է արձանագրության տիպի արձանագրության IPv6 փաթեթ: Նշենք, որ այս պարզունակ չի հալածում արձանագրության շերտի շղթան:

ip6 protochain արձանագրություն

Ճիշտ է, եթե փաթեթը IPv6 փաթեթն է եւ պարունակում է արձանագրության վերնագիր տիպային արձանագրության հետ իր արձանագրության վերնագրի շղթայում: Օրինակ,

ip6 պրոտոչեն 6

համընկնում է IPv6 փաթեթի հետ TCP արձանագրության վերնագրի հետ, արձանագրության վերնագրի շղթայում: Փաթեթը կարող է պարունակել, օրինակ, վավերացման վերնագիր, երթուղիչի վերնագիր կամ hop-by-hop տարբերակի վերնագիր, IPv6 վերնագրի եւ TCP վերնագրի միջեւ: BPF- ի կոդը բարդ է եւ բարդ չէ եւ չի կարող օպտիմալացնել tcpdump- ի BPF optimizer- ի կոդը, ուստի դա կարող է լինել մի փոքր դանդաղ:

ip protochain արձանագրություն

Համապատասխան IP6 protochain արձանագրությանը , բայց դա IPv4- ի համար է:

եթեր հեռարձակումը

Ճիշտ է, եթե փաթեթը Ethernet հեռարձակման փաթեթ է: Էթերի բանալի բառը պարտադիր է:

ip հեռարձակում

Ճիշտ է, եթե փաթեթը IP հեռարձակման փաթեթ է: Այն ստուգում է ինչպես բոլոր zeroes- ի եւ բոլորի կողմից հեռարձակված կոնվենցիաների, եւ նայում է տեղային ենթամաշկի դիմակին:

Ether multicast

Ճիշտ է, եթե փաթեթը Ethernet multicast փաթեթ է: Էթերի բանալի բառը պարտադիր է: Սա ստերիֆ է համարվում ` ether [0] & 1! = 0 ':

ip multicast

Ճիշտ է, եթե փաթեթը IP- ի multicast փաթեթ է:

ip6 multicast

Ճիշտ է, եթե փաթեթը IPv6 multicast փաթեթ է:

Ether proto արձանագրությունը

Ճիշտ է, եթե փաթեթն էթերի տիպի արձանագրության մեջ է : Արձանագրությունը կարող է լինել ip կամ ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx կամ netbeui անունների թվերից կամ մեկը : Նշեք այս նույնացուցիչները նաեւ հիմնաբառեր են եւ պետք է փախչել ճոճանակով (\):

[ FDDI- ի դեպքում (օրինակ, « fddi protocol arp ») եւ Token Ring- ը (օրինակ `« տրոփ արարողակարգ »), այդ արձանագրությունների մեծամասնության համար, արձանագրության նույնականացումը գալիս է 802.2 տրամաբանական կապի վերահսկողության (LLC) վերնագրից, սովորաբար շերտավորվում է FDDI կամ Token Ring- ի գլխավերեւում:

FDDI- ի կամ Token Ring- ի վրա արձանագրության առավելագույն քանակի նույնացուցիչների համար ֆիլտրացման դեպքում tcpdump- ը ստուգում է միայն SNAP ֆորմատով ՍՊԱ -ի վերնագրի պրոտոկոլ ID դաշտը 0x000000- ի կազմակերպական բաժնի նույնացուցիչով (OUI), encapsulated Ethernet- ի համար; այն չի ստուգում, արդյոք փաթեթը գտնվում է SNAP ֆորմատով, 0x000000 OUI- ի հետ:

Բացառություններ են, որ ISO- ն ստուգում է DSAP- ի (նպատակային ծառայության մատչման կետ) եւ SSAP- ի (Աղբյուրների ծառայության մատչման կետ) դաշտերը, որտեղ դրանք ստուգում են ՍՊԸ-ի վերնագրի DSAP- ը եւ ATALK- ում: ստուգում է SNAP ֆորմատով փաթեթ `0x080007-ի OUI- ով եւ Appletalk etype- ով:

Ethernet- ի դեպքում, tcpdump- ը ստուգում է Ethernet տիպի դաշտը այն արձանագրությունների մեծ մասի համար, բացառությամբ, iso , sap եւ netbeui , որոնց համար ստուգում է 802.3 շրջանակ եւ այնուհետեւ ստուգում է ՍՊԸ գլխավոր անվանումը, ինչպես դա անում է FDDI- ի եւ Token Ring- ի համար, որտեղ այն ստուգում է ինչպես Ethernet շրջանակում, այնպես էլ Appletalk- ի համար: SNAP ֆորմատով փաթեթը, ինչպես դա անում է FDDI- ի եւ Token Ring- ի համար, որտեղ այն ստուգում է Appletalk ARP- ի համար, այնպես էլ Ethernet շրջանակում կամ 802.2 SNAP- ի շրջանակում 0x000000- ի OUI- ով եւ ipx- ում , որտեղ ստուգում է IPX- ի տեսակը Ethernet շրջանակ, IPX DSAP- ը ՍՊԸ-ի վերնագրում, 802.3-ը, IPX- ի ոչ մի ՍՊԸ-ի գլխիկների ներգրավմամբ եւ SNAP- ի շրջանակում IPX- ի տեսակը:

decnet src հյուրընկալողը

Ճիշտ է, եթե DECNET- ի աղբյուրի հասցեն հանդիսանում է սերվեր , որը կարող է լինել «10.123» ձեւի հասցեն կամ DECNET host անունը: [DECNET host name support- ը հասանելի է միայն Ultrix համակարգերի վրա, որոնք կազմված են DECNET- ի համար:]

decnet dst հյուրընկալող

Ճիշտ է, եթե DECNET- ի նպատակակետի հասցեն ընդունված է:

դինամիկ ընդունող հյուրատուն

Ճիշտ է, եթե կամ DECNET- ի աղբյուրը կամ ուղղորդիչը հյուրընկալող է :

ip , ip6 , arp , rarp , atalk , aarp , decnet , iso , stp , ipx , netbeui

Հապավումների համար `

էթեր պրոտո բ

որտեղ p- ը վերոհիշյալ արձանագրություններից մեկն է:

լատ , moprc , mopdl

Հապավումների համար `

էթեր պրոտո բ

որտեղ p- ը վերոհիշյալ արձանագրություններից մեկն է: Նշենք, որ tcpdump- ը ներկայումս չի իմանում, թե ինչպես կարելի է վերլուծել այս արձանագրությունները:

vlan [vlan_id]

Ճիշտ է, եթե փաթեթը IEEE 802.1Q VLAN փաթեթ է: Եթե [vlan_id] նշված է, ապա միայն ճշմարիտ է փաթեթը ունի vlan_id- ը : Նշենք, որ արտահայտության մեջ հանդիպող առաջին վանդան բառի փոխարեն փոխում է արտահայտության մնացորդի վերծանման բացթողումները այն ենթադրությամբ, որ փաթեթը VLAN փաթեթ է:

tcp , udp , icmp

Հապավումների համար `

ip proto p կամ ip6 պրոտո պ

որտեղ p- ը վերոհիշյալ արձանագրություններից մեկն է:

iso proto արձանագրություն

Ճիշտ է, եթե փաթեթը հանդիսանում է արձանագրության տիպի արձանագրության OSI փաթեթ: Արձանագրությունը կարող է լինել կլնփ , էիս կամ իսրայելական անունների քանակ կամ մեկը:

clnp , esis , isis

Հապավումների համար `

Իսո պրոտո պ

որտեղ p- ը վերոհիշյալ արձանագրություններից մեկն է: Նշենք, որ tcpdump- ը այս արձանագրությունները վերլուծելու անավարտ աշխատանք է:

expr relop բացատրություն

Ճիշտ է, եթե հարաբերությունը կա, որտեղ relop- ը մեկն է>, <,> =, <=, =,! =, Եւ արտահայտությունը հանդիսանում է թվային շարքերից բաղկացած թվաբանական արտահայտություն (արտահայտված ստանդարտ C շարահյուսության մեջ) , -, *, /, &, |], երկարատեւ օպերատոր եւ հատուկ փաթեթային տվյալներ: Փաթեթի ներսում տվյալները մուտք գործելու համար օգտագործեք հետեւյալ շարադրանքը.

proto [ expr : չափ ]

Proto- ն էթերի, fddi, tr, ppp, slip, հղում, ip, arp, rarp, tcp, udp, icmp կամ ip6- ից է եւ մատնանշում է արձանագրության շերտը ինդեքսի գործողության համար: ( ether, fddi, tr, ppp, slip եւ հղում բոլորը վերաբերում են հղման շերտին): Նշենք, որ tcp, udp եւ այլ վերին շերտի պրոտոկոլային տիպերը կիրառվում են ոչ միայն IPv4- ի համար, այլ նաեւ IPv6: Բայտ օֆսեթը, նշված արձանագրության շերտի համեմատ, տրվում է բացատրությամբ: Չափը պարտադիր է եւ նշում է հետաքրքրության բնագավառում բայտերի քանակը. դա կարող է լինել մեկ, երկու կամ չորս, եւ մեկի համար նախապատվություններ: Len- ի բանալի բառով նշված երկարատեւ օպերատորը տալիս է փաթեթի երկարությունը:

Օրինակ, « ether [0] & 1! = 0 » -ը բոլոր multicast երթեւեկության մասին է: ' Ip [0] & 0xf = 5 ' արտահայտությունը ձեռք է բերում բոլոր IP փաթեթները տարբերակներով: ' Ip [6: 2] & 0x1fff = 0 ' արտահայտությունը միայն unfragmented datagrams- ի եւ fragmented datagrams- ի ֆիրմայի զրոյի մասին է: Այս ստուգումը անուղղակիորեն կիրառվում է tcp եւ udp ինդեքսի գործառնությունների նկատմամբ: Օրինակ, tcp [0] միշտ նշանակում է TCP- ի վերնագրի առաջին բայտը եւ երբեք չի նշանակում միջամտող հատվածի առաջին բայտ:

Որոշ offsets եւ դաշտային արժեքները կարող են արտահայտվել որպես անվան, այլ ոչ թե թվային արժեքներ: Հետեւյալ արձանագրության դաշտի դաշտի դաշտային հաշիվները մատչելի են ` icmptype (ICMP տիպի դաշտ), icmpcode (ICMP կոդը դաշտ) եւ tcpflags (TCP դրոշներ դաշտ):

Հետեւյալ ICMP տիպի դաշտի արժեքները հասանելի են. Icmp-echoreply , icmp-unreach , icmp-sourcequench , icmp- վերահղման , icmp-echo , icmp-routeradvert , icmp-routersolicit , icmp-timxceed , icmp-paramprob , icmp-tstamp , icmp -tstampreply , icmp-ireq , icmp-ireqreply , icmp-maskreq , icmp-maskreply :

Հետեւյալ TCP դրոշների դաշտի արժեքները հասանելի են ` tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-push , tcp-ack , tcp-urg .

Նախատիպերը կարող են օգտագործվել `օգտագործելով`

Պարալիմպիկ խմբեր եւ օպերատորներ (փակագծեր հատուկ են Shell- ին եւ պետք է փախչել):

Negation (« ! » Կամ « ոչ »):

Concatenation (` && 'կամ` եւ '):

Alternation (` || կամ` կամ '):

Negation բարձր առաջադիմություն է: Alternation եւ concatenation- ը հավասարազոր են եւ ձախից աջ: Ուշադրություն դարձրեք, որ կոնցենտրացիայի համար պահանջվում են ակնհայտ եւ նշաններ, այլ ոչ թե համադրություն:

Եթե ​​նույնացուցիչը տրվում է առանց բանալի բառի, ամենավերջին ստեղնը ենթադրվում է: Օրինակ,

ոչ էլ հակառակորդը

կարճ է

այլ ոչ թե հյուրընկալող հյուրեր

որը չպետք է շփոթվի

ոչ (հյուրընկալող կամ հակառակորդ)

Արտահայտման փաստարկները կարող են փոխանցվել tcpdump- ին `որպես մեկ փաստարկ կամ որպես բազմակի փաստարկներ, որոնցից առավել հարմար է: Ընդհանրապես, եթե արտահայտությունը պարունակում է Shell metacharacters- ը, ապա այն ավելի հեշտ է փոխանցել որպես մեկ, մեջբերված փաստարկ: Բազմակի փաստարկները համադրվում են տարածքների հետ, նախքան վերլուծությունը:

Օրինակներ

Երեկոյան ժամանող կամ մեկնող բոլոր փաթեթները տպելու համար.

tcpdump հյուրընկալող կողմ

Ուղղահայաց եւ տաք կամ ace տրաֆիկի տպագրելու համար.

tcpdump host helios եւ \ (տաք կամ ace \)

Տպել բոլոր IP փաթեթները միջեւ ace եւ ցանկացած հյուրընկալող բացի helios :

tcpdump ip host ace եւ ոչ helios

Տպել բոլոր երթեւեկությունը տեղական հյուրընկալող եւ հյուրընկալող է Berkeley:

tcpdump ցանցի ucb-ether

Ինտերնետային դարպասների ցանցի միջոցով բոլոր FTP տրաֆիկները տպելու համար (նշեք, որ արտահայտությունը մեջբերվում է, որպեսզի խցիկի միջամտությունը կանխարգելելուց (mis-) մեկնաբանությունները):

tcpdump- ի դարպասը եւ (port ftp կամ ftp-data)

Թրաֆիկի տպագրման համար ոչ տեղյակ է, ոչ էլ տեղական տանտերերի համար նախատեսված ճակատագիրը (եթե մեկ այլ ցանցի դարպասը, այն երբեք այն չպետք է դարձնի ձեր տեղական ցանցին):

tcpdump ip եւ ոչ թե զուտ լոկալետ

Ցանկացած TCP- ի զրույցի սկիզբ եւ վերջնական փաթեթներ (SYN եւ FIN փաթեթներ) տպելու համար, որը ներառում է ոչ տեղական սերվեր:

tcpdump 'tcp [tcpflags] & (tcp-syn | tcp-fin)! = 0 եւ ոչ src եւ dst net localnet '

IP փաթեթներ ավելի երկար տպելու համար, քան 576 բայթ `ցանցի միջոցով սեղմված միջոցով.

tcpdump- ի դարպասը եւ sn [2: 2]> 576 '

Տպագիր հեռարձակման կամ multicast փաթեթներ տպելու համար, որոնք չեն ուղարկվել ethernet հեռարձակման կամ multicast- ի միջոցով.

tcpdump 'ether [0] & 1 = 0 եւ ip [16]> = 224'

Տպել բոլոր ICMP փաթեթները, որոնք չեն echo հարցումներ / պատասխաններ (այսինքն, ոչ ping փաթեթներ):

tcpdump 'icmp [icmptype]! = icmp-echo եւ icmp [icmptype]! = icmp-echoreply'

ԱՐԴՅՈՔ ՁԵՎԱՉԱՓ

Tcpdump- ի արտադրանքը պրոցեսի կախվածությունն է: Ստորեւ բերված են համառոտ նկարագրություն եւ ձեւաչափերի մեծ մասը:

ՈՒղեցույց մակարդակի ղեկավարներ

Եթե ​​'-e' տարբերակը տրվում է, ապա կապի մակարդակի վերնագիրն տպագրվում է: Հեղինակներ, աղբյուր եւ հասցեի հասցեներ, արձանագրություններ եւ փաթեթի երկարությունը տպագրվում են:

FDDI ցանցերում «-e» տարբերակը պատճառ է դարձնում tcpdump- ը `« շրջանակի հսկողություն »դաշտը, աղբյուրը եւ հասցեի հասցեները եւ փաթեթի երկարությունը: («Շրջանակային հսկողություն» դաշտը կառավարում է մյուս փաթեթի մեկնաբանումը: Պարզ փաթեթները (օրինակ, IP datagram- ները պարունակողները) «async» փաթեթներն են, 0-ից 7-ի համար առաջնային արժեքով, օրինակ, ` async4 ': փաթեթները ենթադրվում են պարունակել 802.2 տրամաբանական կապի վերահսկում (ՍՊԸ) փաթեթ, ՍՊԸ-ի վերնագիրն տպագրվում է, եթե դա ISO datagram կամ այսպես կոչված SNAP փաթեթ:

Token Ring- ի ցանցերում «-e» տարբերակը պատճառ է դարձնում tcpdump- ը տպելու «մուտքի հսկման» եւ «շրջանակի հսկման» դաշտերը, աղբյուրը եւ հասցեի հասցեները եւ փաթեթի երկարությունը: Ինչ վերաբերում է FDDI ցանցերին, ապա փաթեթները ենթադրվում են պարունակել ՍՊԸ փաթեթ: Անկախ նրանից, թե '-e' տարբերակը նշված է թե ոչ, աղբյուրի երթուղայնացման տեղեկատվությունը տպագրվում է աղբյուրի ուղղորդված փաթեթների համար:

(NB: Հետեւյալ նկարագրությունը ենթադրում է RFC-1144-ում նկարագրված SLIP կոմպրեսիոն ալգորիթմի մասին):

SLIP- ի հղումների վրա ուղղորդող ցուցիչ (`` `ներգնա` `` '' դուրս գալուն ''), փաթեթի տեսակը եւ սեղմման տեղեկատվությունը տպագրվում են: Փաթեթի տեսակը տպագրվում է նախապես: Երեք տեսակներ են ip , utcp եւ ctcp : Հետագա կապի տեղեկատվությունը տպված չէ ip փաթեթների համար: TCP- ի փաթեթների համար կապի նույնացուցիչը տպագրվում է ըստ տեսակի: Եթե ​​փաթեթը սեղմված է, նրա կոդավորված վերնագիրն տպագրվում է: Հատուկ դեպքերն արտացոլվում են որպես * S + n եւ * SA + n , որտեղ n - այն գումարը, որով հաջորդականության համարը (կամ հերթական համարը եւ ack) փոխվել է: Եթե ​​դա հատուկ դեպք չէ, ապա զրո կամ ավելի շատ փոփոխություններ են տպագրվում: Փոփոխությունը նշվում է U (հրատապ ցուցիչ), W (պատուհան), A (ack), S (հաջորդականության համարը) եւ I (փաթեթ ID), այնուհետեւ դելտա (+ n կամ -n) կամ նոր արժեք (= n): Վերջապես, փաթեթի եւ սեղմված վերնագրի երկարության տվյալների քանակը տպագրվում է:

Օրինակ, հետեւյալ տողը ցույց է տալիս ելքային սեղմված TCP փաթեթը `անուղղակի կապի նույնացուցիչով; 6-ը փոխվել է, հաջորդականությունը `49-ով, իսկ փաթեթի ID- ն` 6-ով: կան 3 բայտ տվյալների եւ սեղմված վերնագրի 6 բայթ:

O ctcp * A + 6 S + 49 I + 6 3 (6)

ARP / RARP փաթեթներ

Arp / rarp արտադրանքը ցույց է տալիս հարցման տեսակը եւ դրա փաստարկները: Ֆորմատը նախատեսված է ինքնաբացարկի համար: Ահա մի կարճ նմուշ, որը վերցված է «rlogin» - ի կողմից, հյուրընկալող հյուրերից մինչեւ csam :

arp, ով ունի csam- ը, ասում է, որ պատասխանատու է CSAM- ին

Առաջին տողում ասվում է, որ rtsg- ը ուղարկել է արբ փաթեթ, խնդրելով ինտերնետային հյուրընկալող csam- ի ethernet հասցեով: Csam- ը պատասխան է տալիս իր Ethernet- ի հասցեով (այս օրինակում, ethernet հասցեները գտնվում են կափարիչներով եւ ինտերնետային հասցեներով, ստորին դեպքում):

Դա կլիներ նվազ պակաս, եթե մենք արեցինք tcpdump -n :

arp ով ունի 128.3.254.6 պատմել 128.3.254.68 arp պատասխան 128.3.254.6 է 02: 07: 01: 00: 01: c4

Եթե ​​մենք արել ենք tcpdump- ը , այն փաստը, որ առաջին փաթեթը հեռարձակվում է, իսկ երկրորդը `կետ-կետ, տեսանելի կլինի.

RTSG հեռարձակում 0806 64: arp, ով ունի csam- ի մասին rtsg CSAM RTSG 0806 64: arp պատասխանը csam- ը `CSAM- ում

Առաջին փաթեթի համար սա նշում է, որ Ethernet աղբյուրի հասցեն RTSG է, որի նպատակն է ethernet հեռարձակման հասցե, տիպի դաշտը պարունակում է hex 0806 (տիպ ETHER_ARP) եւ ընդհանուր երկարությունը, 64 բայթ:

TCP փաթեթներ

(NB: Հետեւյալ նկարագրությունը ենթադրում է ծանոթություն TCP արձանագրության մեջ նկարագրված RFC-793-ում: Եթե դուք չեք ծանոթ արձանագրությանը, ոչ այս նկարագրությունը, ոչ էլ tcpdump- ը ձեզ համար շատ օգտակար չի լինի):

Tcp արձանագրության գծի ընդհանուր ձեւաչափը հետեւյալն է.

src> dst: դրոշները տվյալների - սյունակային պատուհանի հրատապ տարբերակները

Src եւ dst- ը աղբյուրի եւ նշանակման IP հասցեներն ու նավահանգիստներն են: Դրոշները S (SYN), F (FIN), P (PUSH) կամ R (RST) կամ մեկ `որոշակի համադրություն են: (դրոշներ): Data-seqno- ն նկարագրում է այս փաթեթի տվյալների ծածկված հաջորդականության հատվածի մասը (տես ստորեւ բերված օրինակ): Ack- ը հերթական համարն է, որը ակնկալում է այս կապակցությամբ այլ ուղղություն: Պատուհանը բուֆերային տարածք ստանալու բայթերի քանակն է, որը հասանելի է այս ուղղությամբ: Ուրգը մատնանշում է փաթեթում առկա «անհետաձգելի» տվյալներ: Ընտրանքներ են tcp տարբերակները, որոնք կցված են անկյունագծային փակագծերում (օրինակ, ):

Src, dst եւ դրոշները միշտ ներկա են: Մյուս դաշտերը կախված են փաթեթի tcp արձանագրության վերնագրի բովանդակությունից եւ արտադրվում են միայն համապատասխան դեպքերում:

Ահա մի rlogin- ի բացումը, որը տեղի է ունենում հյուրընկալող հյուրերից :

rtsg.1023> csam.login: S 768512: 768512 (0) հաղթել 4096 csam.login> rtsg.1023: S 947648: 947648 (0) ack 768513 հաղթել 4096 rtsg.1023> csam: մուտք:. ack 1 հաղթել 4096 rtsg.1023> csam.login: P 1: 2 (1) ack 1 հաղթել 4096 csam.login> rtsg.1023:. 2 հաղթանակ 4096 rtsg.1023> csam.login: P 2:21 (19) 1 հաղթանակ 4096 csam.login> rtsg.1023: P 1: 2 (1) ack 21 win 4077 csam.login> rtsg.1023: P 2: 3 (1) ack 21 հաղթանակ 4077 շտապ 1 csam.login> rtsg.1023: P 3: 4 (1) 21 հաղթանակ 4077 շտապ 1

Առաջին տողում նշվում է, որ rtsg- ի tcp port 1023-ը փաթեթ ուղարկեց csam- ում նավահանգիստ մուտք գործելու համար: S- ը նշում է, որ SYN դրոշը սահմանվել է: Փաթեթի հաջորդականության համարը 768512 էր, եւ այն պարունակում էր տվյալներ: (Նշում `առաջին` վերջին (nbytes) ', որը նշանակում է `հաջորդականության համարները, նախքան վերջին , բայց ոչ վերջինը, որը օգտագործողի տվյալների տվյալների մեջ է` nbytes bytes): Չկա խոզուկով հենված սկավառակ, առկա ստացվող պատուհանը 4096 բայթ էր եւ գոյություն ունեցավ max-segment-size տարբերակը, որը պահանջում էր mss 1024 բայթ:

Csam- ը պատասխանում է նմանատիպ փաթեթի հետ, բացառությամբ այն, որը ներառում է rtsg- ի SYN- ի համար խոզուկով ապահովված: Rtsg ապա csam- ի SYN- ին խանգարում է: «. նշանակում է դրոշներ չեն սահմանվել: Փաթեթը պարունակում է տվյալներ, որպեսզի տվյալների հաջորդականության համարը չկա: Նշենք, որ ack հաջորդականության համարը փոքր թիվ է (1): Առաջին անգամ tcpdump- ը տեսնում է « tcp` զրույցը», այն հաջորդականության համարը տպում է փաթեթից: Զրույցի հետագա փաթեթներում, ընթացիկ փաթեթի հերթական համարի եւ այս նախնական հաջորդականության թվերի տարբերությունը տպագրվում է: Սա նշանակում է, որ առաջին հերթին հաջորդականության թվերը կարելի է մեկնաբանել որպես հարաբերական բայտ դիրքորոշում զրույցի տվյալների հոսքի մեջ (առաջին տվյալների բայթ յուրաքանչյուր ուղղությամբ `1): «-Ս» -ը կվերանվանվի այս հատկությունը, պատճառելով արտադրանքի սկզբնական հաջորդականությունը:

6-րդ գիծում rtsg- ն ուղարկում է տվյալների 19 հատ բայտ (բծերի 2-ից 20-ը `rtsg- ի խոսակցական կողմում): PUSH դրոշը փաթեթում է: 7-րդ տողում csam- ն ասում է, որ ստացել է rtsg- ի կողմից ուղարկված տվյալներ, բայց ոչ բայտ 21: Տվյալների մեծ մասը ակնհայտորեն նստած է վարդակային բուֆերի մեջ, քանի որ csam- ի պատուհանը ստացել է 19 բայթ փոքր: Csam- ը նաեւ մեկ բայտ տվյալներ է հաղորդում այս փաթեթում: 8-րդ եւ 9-րդ տողերում csam- ն ուղարկում է երկու բայթեր `հրատապ, հրատապ տվյալների rtsg- ին:

Եթե պատկերն այնքան փոքր էր, որ tcpdump- ը չի գրավում ամբողջական TCP- ի վերնագիրը, ապա այն վերլուծում է այն, ինչ հնարավոր է, այնուհետեւ `[` tcp ] '' նշելու համար, որ մնացորդը չի կարող մեկնաբանվել: Եթե ​​վերնագիրն պարունակում է կեղծիքի տարբերակ (մեկը, որը չափազանց փոքր է կամ վերնագրի վերջից դուրս), tcpdump- ը այն ներկայացնում է որպես «[ վատ ընտրություն ]» եւ չի մեկնաբանում որեւէ այլ տարբերակ (քանի որ անհնար է ասել որտեղ նրանք սկսում են): Եթե ​​վերնագրի տեւողությունը ցույց է տալիս, որ ընտրանքները ներկա են, սակայն IP դետադաշտի երկարությունը բավարար չէ, այնուամենայնիվ, ընտրանքների իրականում այնտեղ կա, tcpdump- ը հաղորդում է այն որպես «[ վատ Hdr երկարություն ]»:

TCP փաթեթների առգրավելու առանձին դրոշի համակցություններով (SYN-ACK, URG-ACK եւ այլն)

TCP- ի վերնագրի վերահսկողության բիթերի բաժնում առկա են 8 բիթ:

CWR | ECE | | URG | ACK | PSH | RST | SYN | FIN

Ենթադրենք, մենք ուզում ենք դիտել TCP կապի ստեղծման համար օգտագործվող փաթեթները: Հիշեք, որ TCP- ն օգտագործում է 3-way handshake արձանագրությունը, երբ այն նորացնում է նոր կապը: TCP- ի կառավարման բիտերի հետ կապի հաջորդականությունը

1) Զանգողը ուղարկում է SYN

2) Ստացողը արձագանքում է SYN- ի, ACK- ի հետ

3) զանգահարողը ուղարկում է ACK

Այժմ մենք շահագրգռված ենք միայն SYN բիթի փաթեթով (1-ին քայլ) փաթեթներ գրավելով: Նշենք, որ մենք 2-րդ քայլից (SYN-ACK) փաթեթներ չենք ուզում, պարզապես պարզ նախնական SYN: Այն, ինչ մենք պետք է, ճշգրիտ զտիչ արտահայտություն է tcpdump- ի համար :

Հիշեք TCP- ի վերնագրի կառուցվածքը `առանց ընտրանքների.

0 15 31 ----------------------------------------------- ------------------ | աղբյուր նավահանգիստ | նպատակակետ նավահանգիստ | -------------------------------------------------- --------------- | հաջորդականության համարը | -------------------------------------------------- --------------- | ճանաչման համարը | -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | պատուհանի չափը | -------------------------------------------------- --------------- | TCP checksum | հրատապ ցուցիչ | -------------------------------------------------- ---------------

TCP- ի թղթապանակը սովորաբար պահպանում է 20 octets տվյալներ, եթե հնարավոր չէ: Գրաֆիկի առաջին գիծը պարունակում է 0 - 3 octets, երկրորդ տողը ցույց է տալիս octets 4 - 7 եւ այլն:

0-ից հաշվելը սկսվում է համապատասխան TCP- ի կառավարման բիտերը պարունակում են octet 13:

0 7 | 15 | 23 | 31 ---------------- | --------------- | --------------- | ---------------- | HL | rsvd | C | E | U | A | P | R | S | F | պատուհանի չափը | ---------------- | --------------- | --------------- | - --------------- | | | 13-րդ octet | | | | |

Եկեք ավելի սերտ նայենք octet- ից no. 13:

| | | | | --------------- | C | E | U | A | P | R | S | F | | --------------- | | 7 5 3 0 |

Սրանք են TCP- ի վերահսկման բիթները, որոնք մենք շահագրգռված ենք: Այս octet- ում մենք թվարկեցինք 0-ից 7-ը, աջից ձախ, այնպես որ PSH- ն քիչ է 3-րդ, իսկ URG- ն `5-ն:

Հիշեցնենք, որ մենք ցանկանում ենք փաթեթներ գրավել միայն SYN- ի հավաքածուով: Եկեք տեսնենք, թե ինչ է տեղի ունենում octet- ի 13-ում, եթե TCP- ն մտնում է իր վերնագրի SYN բիթով:

C | E | U | A | P | R | S | F | | --------------- | | 0 0 0 0 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 | |

Ստուգելով հսկիչ բիթերի բաժինը, մենք տեսնում ենք, որ միայն բիթի թիվ 1 (SYN) է սահմանվում:

Հաշվի առնելով, որ թիվ 13 octet- ը 8 բիտանոց ստորագրված ամբողջ թիվ է ցանցային բայտ կարգով, այս octet- ի երկուական արժեքը

00000010

եւ նրա տասնորդական ներկայացումը

7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 2

Մենք գրեթե արեցինք, քանի որ հիմա մենք գիտենք, որ եթե միայն SYN- ն է սահմանվում, TCP- ի վերնագրի 13-րդ octet- ի արժեքը, երբ մեկնաբանվում է որպես 8 բիթ ստորագրված ամբողջական բջջային բայտ կարգով, պետք է լինի հենց 2:

Այս հարաբերությունները կարող են արտահայտվել որպես

tcp [13] == 2

Մենք կարող ենք օգտագործել այս արտահայտությունը, որպես tcpdump- ի զտիչ, փաթեթների դիտման համար, որոնք միայն SYN- ն ունեն:

tcpdump -i xl0 tcp [13] == 2

Արտահայտությունը ասում է, «թող TCP datagram- ի 13-րդ octet- ը ունի տասնորդական արժեք 2», ինչը հենց այն է, ինչ ուզում ենք:

Հիմա, եկեք ենթադրենք, որ մենք պետք է գրավել SYN փաթեթները, բայց մեզ չի հետաքրքրում, եթե միաժամանակ ACK կամ որեւէ այլ TCP վերահսկողության բիթ: Եկեք տեսնենք, թե ինչ է տեղի ունենում octet- ի 13-ում, երբ TCP- ն դինամիկ է SYN-ACK- ի հետ:

C | E | U | A | P | R | S | F | | --------------- | | 0 0 0 1 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 | |

Այժմ 1-ին եւ 4-րդ բիտերը սահմանված են 13-րդ octet- ում: Octet 13-ի երկուական արժեքը

00010010

որը թարգմանում է տասնորդական

7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 18

Այժմ մենք չենք կարող օգտագործել միայն tcpdump ֆիլտրի արտահայտության մեջ 'tcp [13] == 18', քանի որ այն կընտրեր միայն SYN- ACK- ի փաթեթներ, բայց ոչ միայն SYN- ի փաթեթը: Հիշեք, որ մենք չենք մտածում, եթե ACK- ն կամ որեւէ այլ հսկիչ բիտ է սահմանված, քանի դեռ SYN- ը սահմանվում է:

Մեր նպատակին հասնելու համար հարկավոր է տրամաբանորեն եւ octet 13-ի երկուական արժեքը որոշ այլ արժեքներով պահպանել SYN բիթը: Մենք գիտենք, որ մենք ցանկանում ենք, որ SYN- ը դառնա ցանկացած դեպքում, այնպես որ մենք տրամաբանականորեն եւ արժեքը 13-րդ octet- ում `SYN- ի երկուական արժեքով.

00010010 SYN-ACK 00000010 SYN AND 00000010 (մենք ուզում ենք SYN) եւ 00000010 (մենք ուզում ենք SYN) -------- -------- = 00000010 = 00000010

Մենք տեսնում ենք, որ այս եւ գործողության արդյունքում ստացվում է նույն արդյունքը `անկախ ACK- ն կամ այլ TCP- ի կառավարման բիտ: AND- ի տասնորդական ներկայացումը, ինչպես նաեւ այդ գործողության արդյունքը 2 է (երկուական 00000010), այնպես որ մենք գիտենք, որ SYN- ի փաթեթների համար սահմանվում է հետեւյալ հարաբերությունը,

((octet 13 արժեքը) եւ (2)) == (2)

Սա ցույց է տալիս մեզ tcpdump ֆիլտրի արտահայտությանը

tcpdump -i xl0 'tcp [13] & 2 == 2'

Նշենք, որ դուք պետք է օգտագործեք միեւնույն մեջբերում կամ արտահայտված արտահայտության մեջ շերտից եւ (& ') հատուկ բնույթը թաքցնելու համար:

UDP փաթեթներ

UDP ձեւաչափը պատկերված է այս փաթեթի կողմից:

actinide.who> broadcast.who: udp 84

Սա ասում է, որ նավահանգիստը, որը հյուրընկալող actinide- ում ուղարկել է udp datagram- ին նավահանգստում, որը հյուրընկալող հաղորդման ժամանակ ինտերնետի հեռարձակման հասցե է: Փաթեթը պարունակում էր 84 բայթ օգտվող տվյալներ:

Որոշ UDP ծառայություններ ճանաչվում են (աղբյուրի կամ նշանակման նավահանգստի համարից) եւ ավելի բարձր մակարդակի արձանագրության մասին տեղեկությունները տպագրված են: Մասնավորապես, Domain Name ծառայության դիմումները (RFC-1034/1035) եւ Sun RPC- ն (RFC-1050) զանգահարում է NFS- ին:

UDP անունով սերվերային պահանջներ

(NB: Հետեւյալ նկարագրությունը ենթադրում է ծանոթություն RFC-1035-ում նկարագրված Դոմեն ծառայության ծառայության արձանագրությունին: Եթե դուք ծանոթ չեք արձանագրությանը, հունարենում գրված է հետեւյալ նկարագրությունը:)

Անունի սերվերի պահանջները ձեւաչափված են

src> dst: id op- ը: դրոշներ qtype qclass անունը (len) h2opolo.1538> helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

Host h2opolo խնդրեց տիրույթի սերվերի վրա helios համար հասցեն գրառումը (qtype = A) հետ կապված անունով ucbvax.berkeley.edu. Հարցման ID- ն էր `3`: «+» - ը նշում է, որ ցանկալի ցանկը դրոշակ է: Հարցման երկարությունը եղել է 37 բայթ, ներառյալ UDP եւ IP- ի արձանագրության վերնագրերը: Հարցման գործողությունը նորմալ էր, հարցումը , այնպես որ op դաշտը բացակայում է: Եթե ​​օփը այլ բան էր, ապա այն կցագրվեր «3» եւ «+» միջեւ: Նմանապես, qclass- ը նորմալ էր, C_IN եւ բաց թողնված: Ցանկացած այլ qclass- ը տպագրվել է անմիջապես «A» - ից հետո:

Մի քանի անոմալիա է ստուգվում եւ կարող է հանգեցնել ավելցուկային դաշտերի քառակուսի փակագծերում: Եթե հարցումը պարունակում է պատասխան, հեղինակային գրառումներ կամ լրացուցիչ գրառումներ բաժնում, հաշվում , nscount կամ arcount , տպագրվում են որպես [ n a], `[ n n ] կամ `[ n au], որտեղ n- ը պատշաճ հաշվարկ է: Եթե ​​պատասխանատներից որեւէ մեկը սահմանված է (AA, RA կամ rcode) կամ ցանկացած «պետք է զրոյական» բիթներ տեղադրվեն երկու եւ երեք բայթերում `[b2 & 3 = x ] տպագրված է, որտեղ x- ը վերնագիր բայտ երկու եւ երեք:

UDP Name Server- ի պատասխանները

Անուն սերվերի պատասխանները ձեւաչափված են

src> dst: id- ի rcode դրոշներ a / n / au տիպի դասի տվյալները (len) helios.domain> h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) helios.domain> h2opolo.1537: 2 NXDomain * 0/1/0 (97)

Առաջին օրինակին, հելիոններն արձագանքում են h2opolo- ից հարցման id 3-ին, 3 պատասխան գրառումով, 3 անունի սերվերային գրառում եւ 7 լրացուցիչ գրառում: Առաջին պատասխան գրառումը A- ն է (հասցեն) եւ դրա տվյալները ինտերնետի հասցեն `128.32.137.3: Պատասխանի ընդհանուր չափը եղել է 273 բայ, բացառությամբ UDP եւ IP- ի վերնագրերի: The op (Query) եւ արձագանքման կոդ (NoError) բաց թողնված էին, ինչպես A ռեկորդի դասը (C_IN):

Երկրորդ օրինակում, հելիոններն արձագանքում են 2-րդ հարցին, ոչ պատասխանի հետ չկատարված տիրույթի (NXDomain) պատասխան կոդով, մեկ անուն սերվերի եւ հեղինակային իրավունքի որեւէ գրառում: «*» -ը նշում է, որ հեղինակավոր պատասխանը սահմանվել է: Քանի որ ոչ մի պատասխան չկար, տպագրված որեւէ տեսակի, դասի կամ տվյալների վրա:

Այլ դրոշի նիշերը, որոնք կարող են հայտնվել `` `(ռեզուսորս մատչելի է, RA, սահմանված չէ) եւ` | ' (կրճատված հաղորդագրություն, TC, հավաքածու): Եթե ​​հարցի բաժինը չի պարունակում մեկ գրառում, ապա `[ n q ]- ը տպագրվում է:

Նշենք, որ անունը սերվերի պահանջներն ու պատասխանները մեծ են, եւ 68 բայթերի նախնական կոճակները չեն կարող գրավել տպագիր փաթեթը: Օգտագործեք դրոշը, որպեսզի ավելացնեք շեղը, եթե անհրաժեշտ է լրջորեն ուսումնասիրել անունը սերվերի երթեւեկությունը: -13- ը լավ է աշխատել ինձ համար:

SMB / CIFS վերծանումը

tcpdump- ն այժմ ներառում է բավականին լայնածավալ SMB / CIFS / NBT վերծանումը UDP / 137, UDP / 138 եւ TCP / 139 տվյալների համար: Կատարվում է նաեւ IPX- ի եւ NetBEUI SMB- ի տվյալների որոշ պարզունակ ապակոդավորում:

Լռելյայնորեն կատարվում է բավականին նվազագույն decode, որն ավելի շատ մանրամասն վերծանվեց, եթե օգտագործվում է -v- ը: Եղեք զգուշացրեք, որ «-va» առանձին SMB փաթեթով կարող է էջ կամ ավելի շատ վերցնել, այնպես որ միայն օգտագործեք -v եթե դուք իսկապես ուզում եք բոլոր գորշ մանրամասները:

Եթե ​​դուք decoding SMB նիստերը պարունակող unicode տողերի, ապա դուք կարող եք սահմանել շրջակա միջավայրի փոփոխական USE_UNICODE է 1. Patch է ավտոտնտեսություն unicode srings կլինի ողջունելի է:

SMB փաթեթի ձեւաչափերի վերաբերյալ տեղեկությունների համար եւ ինչի համար է նշվում www.cifs.org կամ pub / samba / specs / directory ձեր սիրած samba.org հայելու վայրում: SMB- ի պատերը գրվել են Էնդրյու Թրեյգելի կողմից (tridge@samba.org):

NFS հարցումներ եւ պատասխաններ

Sun NFS (Network File System) հարցումները եւ պատասխանները տպագրվում են հետեւյալ կերպ,

src.xid> dst.nfs: len op args src.nfs> dst.xid: պատասխանել վիճակագրության արդյունքների sushi.6709> wrl.nfs: 112 readlink fh 21,24 / 10.73165 wrl.nfs> sushi.6709: Պատասխանել ok 40 readlink "../var" sushi.201b> wrl.nfs: 144 lookup fh 9,74 / 4096,6878 «xcolors» wrl.nfs> sushi.201b: պատասխան ok 128 lookup fh 9,74 / 4134,3150

Առաջին տողում հյուրընկալող սուշի գործի է դնում 6709 ID- ի հետ կնքված գործարք (նշեք, որ src- ի հաջորդ սերվերը համարվում է գործարքի ID, այլ ոչ թե աղբյուրի նավահանգիստ): Հայցը 112 բայթ էր, բացառությամբ UDP եւ IP- ի վերնագրերի: Գործողությունը եղել է readlink (կարդալ խորհրդանշական հղումը) ֆայլի բռնակի վրա ( fh ) 21,24 / 10.731657119: (Եթե մեկը հաջողակ է, քանի որ այս դեպքում ֆայլի բռնիչը կարելի է մեկնաբանել որպես խոշոր, անլար սարքի համարի զույգ, հետեւաբար inode- ի եւ սերնդի համարը:) Wrl- ը պատասխանում է `հղումը բովանդակության հետ:

Երրորդ գծում, սուշի խնդրում է wrl փնտրել անունը ` xcolors 'ի դիրեկտորիայի ֆայլի 9,74 / 4096,6878: Նշենք, որ տպագրված տվյալները կախված են գործողությունից: Ֆորմատը նախատեսված է ինքնաբացարկի համար, եթե կարդացվի NFS պրոտոկոլի առանձնահատկությամբ:

Եթե ​​-v (մանրամասն) դրոշը տրվում է, լրացուցիչ տեղեկատվություն տպագրվում է: Օրինակ:

sushi.1372a> wrl.nfs: 148 կարդալ fh 21,11 / 12.195 8192 bytes @ 24576 wrl.nfs> sushi.1372a: պատասխան ok 1472 կարդալ REG 100664 ids 417/0 sz 29388

(-v- ը նաեւ տպում է IP- ի վերնագիր TTL- ի, ID- ի, երկարության եւ մասնատման դաշտերը, որոնք բացակայում են այս օրինակումից): Առաջին շարքում sushi- ն խնդրում է 8192 բայթ կարդալ 21,11 / 12.195 ֆայլից, բայտ օֆսեթ 24576. Wrl- ի պատասխանները `ok '; երկրորդ շարքում ցուցադրված փաթեթը պատասխանի առաջին հատվածն է, եւ դրա համար ընդամենը 1472 բայթ (մյուս բայթները հաջորդական հատվածներում կհայտնվեն, բայց այդ բեկորները չունեն NFS կամ նույնիսկ UDP վերնագրեր եւ այդպիսով չեն կարող տպագրվել, կախված օգտագործվող ֆիլտրի արտահայտությունից): Քանի որ -v դրոշը տրվում է, ֆայլի որոշ հատկանիշներ (որոնք վերադարձվում են ֆայլի տվյալների լրացման համար) տպվում են. Ֆայլի տեսակը (`` REG '', հերթական ֆայլի համար), ֆայլի ռեժիմը (octal), uid եւ gid, եւ ֆայլի չափը:

Եթե ​​-v դրոշը տրվում է ավելի քան մեկ անգամ, ապա ավելի շատ մանրամասներ են տպագրվում:

Նշենք, որ NFS- ի պահանջները շատ մեծ են, եւ մանրամասնությունը շատ չի տպագրվի, քանի դեռ չի աճում: Փորձեք օգտագործել ` -192` NFS երթեւեկությունը դիտելու համար:

NFS- ի պատասխանող փաթեթները չեն բացահայտում RPC- ի գործողությունը: Փոխարենը, tcpdump- ը շարունակում է հետեւել «վերջին» պահանջներին եւ համապատասխանում է դրանք գործարքային ID- ի օգտագործած պատասխաններին: Եթե ​​պատասխանը չի համապատասխանում համապատասխան խնդրանքին, ապա դա չի կարող ենթարկվել:

AFS հարցումներ եւ պատասխաններ

Transarc AFS- ը (Andrew File System) հարցումները եւ պատասխանները տպագրվում են հետեւյալ կերպ.

src.sport> dst.dport: rx փաթեթային տիպի src.sport> dst.dport: rx փաթեթային տիպի ծառայության զանգի զանգի անուն args src.sport> dst.dport: rx փաթեթային տիպի ծառայություն պատասխանել զանգի անունը args elvis: 7001> pike.afsfs: rx տվյալների fs զանգահարեք վերանվանել անունը 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" pike.afsfs> elvis.7001: rx տվյալների fs պատասխանել վերանվանել

Առաջին տողում էլվիսը RX- ի փաթեթ է ուղարկում: Սա RX տվյալների փաթեթ էր fs (fileserver) ծառայության համար եւ RPC զանգի սկիզբն է: RPC- ի զանգը վերանվանվել է, 536876964/1/1 հին տեղեկատուի ֆայլի ID- ով եւ `.newsrc.new- ի հին ֆայլի անվանմամբ եւ 536876964/1/1 նոր դիրեկտորիայի ֆայլի եւ '. newsrc '. Տանտիրուհին արձագանքում է RPC- ի պատասխանին վերանվանելու կոչին (որը հաջող էր, քանի որ դա տվյալների փաթեթ էր եւ ոչ թե բաժանված փաթեթ):

Ընդհանուր առմամբ, բոլոր AFS RPC- ները գաղտնագրվում են առնվազն RPC զանգի անունով: AFS RPC- ների մեծ մասը ունեն առնվազն որոշ փաստարկներ (ընդհանրապես միայն «հետաքրքիր» փաստարկներ, հետաքրքիր որոշակի սահմանումը):

Ֆորմատը նախատեսված է ինքնորոշման համար, բայց դա, հավանաբար, օգտակար չէ այն մարդկանց համար, ովքեր ծանոթ չեն AFS- ի եւ RX- ի աշխատանքի:

Եթե ​​-v (մանրամասն) դրոշը տրվում է երկու անգամ, ճանաչման փաթեթներ եւ լրացուցիչ վերնագիր տեղեկատվություն, ինչպիսիք են RX զանգի ID- ն, զանգի համարը, հաջորդականության համարը, սերիական համարը եւ RX փաթեթի դրոշները:

Եթե ​​-v դրոշը երկու անգամ տրվում է, լրացուցիչ տեղեկատվություն տպագրվում է, օրինակ, RX- ի զանգի ID- ն, սերիական համարը եւ RX փաթեթի դրոշները: MTU- ի բանակցային տեղեկատվությունը տպագրվում է նաեւ RX ack փաթեթներից:

Եթե ​​-v դրոշը տրվում է երեք անգամ, ապա տպագրվում է անվտանգության ինդեքսը եւ ծառայողական id:

Սխալ կոդերը տպագրվում են բաժանված փաթեթների համար, բացառությամբ Ubik հրահանգիչի փաթեթների (քանի որ բաժանված փաթեթները օգտագործվում են «Ուբիկ» արձանագրության համար այո քվեարկելու համար):

Նշենք, որ AFS- ի հարցումները շատ մեծ են եւ փաստարկներից շատերը չեն տպագրվելու, քանի դեռ չեն արտացոլվել : Փորձեք օգտագործել ` -s 256` AFS երթեւեկությունը դիտելու համար:

AFS- ի պատասխան փաթեթները չեն բացահայտում RPC- ի գործողությունը: Փոխարենը, tcpdump- ը շարունակում է հետեւել «վերջին» պահանջներին եւ համապատասխանում է այն պատասխաններին, օգտագործելով զանգի համարը եւ սպասարկման նույնականացումը: Եթե ​​պատասխանը չի համապատասխանում համապատասխան խնդրանքին, ապա դա չի կարող ենթարկվել:

KIP Appletalk (DDP- ի UDP- ում)

UDP դիագրամներում ներառված Appletalk DDP փաթեթներն անջատված են եւ արտահոսում են որպես DDP փաթեթներ (այսինքն, բոլոր UDP- ի վերնագրի տեղեկատվությունը վերացվում է): /etc/atalk.names ֆայլը օգտագործվում է appletalk ցանցի եւ հանգույցի համարները թարգմանելու համար: Այս ֆայլի տողերը ունեն ձեւաթուղթ

անուն ազգանունը 1.254 ether 16.1 icsd-net 1.254.110 ace

Առաջին երկու տողը տալիս է appletalk ցանցերի անունները: Երրորդ գիծը տալիս է որոշակի տերմինի անունը (հյուրընկալողը ցանցում զետեղված է ցանցի 3-րդ octet- ի կողմից `զուտ թիվը պետք է ունենա երկու octets, իսկ հյուրընկալող համարը պետք է ունենա երեք octets): Թվայինը եւ անունը պետք է առանձնացվեն ըստ սպիտակեղենի (բացվածքներ կամ ներդիրներ): /etc/atalk.names ֆայլը կարող է պարունակել դատարկ տողեր կամ մեկնաբանություններ տողեր (գծեր, սկսած `# '):

Appletalk հասցեները տպագրվում են հետեւյալ ձեւով.

net.host.port 144.1.209.2> icsd-net.112.220 գրասենյակ.2> icsd-net.112.220 jssmag.149.235> icsd-net.2

(Եթե /etc/atalk.names- ը գոյություն չունի կամ չի պարունակում որոշակի appletalk host / net number- ի համար, հասցեները տպվում են թվային ձեւով): Առաջին օրինակում NBP (DDP port 2) զուտ 144.1 հանգույցը 209-ն ուղարկում է այն ամենին, ինչ լսել է նավահանգստի ցանցի 220-ը 220-ի վրա: Երկրորդ շարքը նույնն է, բացառությամբ աղբյուրի հանգույցի լրիվ անունը հայտնի է («գրասենյակ»): Երրորդ գիծը 235-ի նավահանգստից ուղարկել է ցանցի jssmag node 149-ում, եթերային ցանցի NBP նավահանգստում հեռարձակելու համար (նշեք, որ հեռարձակման հասցեը (255) նշվում է զուտ անունով, առանց հյուրընկալող համարի `այդ պատճառով լավ գաղափար է կախված անունների եւ զուտ անունների պահպանումը /etc/atalk.names- ում:

NBP (անվանումը պարտադիր արձանագրությունը) եւ ATP (Appletalk գործարքի արձանագրությունը) փաթեթները ունեն իրենց բովանդակությունը մեկնաբանված: Այլ արձանագրությունները պարզապես վերացնում են արձանագրության անունը (կամ համարը, եթե արձանագրության համար անուն չի գրանցվել) եւ փաթեթի չափը:

NBP փաթեթները ձեւափոխված են հետեւյալ օրինակներով.

icsd-net.112.220> jssmag.2: nbp-lkup 190: "=: LaserWriter @ *" jssmag.209.2> icsd-net.112.220: nbp- պատասխան 190: "RM1140: LaserWriter @ *" 250 techpit.2> icsd -լտր.112.220: nbp- պատասխան 190: «Տեխնոլոգիա. լազերային գրիչ @» 186

Առաջին տողը ցանցային icsd ընդունիչ 112-ի կողմից ուղարկված laserwriters- ի անունների որոնման հայտ եւ հեռարձակվում jssmag ցանցում: Փնտրման համար nbp ID- ն 190 է: Երկրորդ տողը ցույց է տալիս, որ այս խնդրանքի պատասխանը (նշեք, որ նույն ID ունի) host jssmag- ից: 209-ը նշում է, որ ունի 250-րդ նավահանգստում գրանցված «RM1140» լազերային ռեսուրս: գիծը նույն հարցման մեկ այլ պատասխան է, որն ասում է, որ տանտիրուհին ունի 186 նավահանգստում գրանցված laserwriter "techpit":

ATP փաթեթի ձեւաչափումը ցուցադրվում է հետեւյալ օրինակով.

jssmag.209.165> helios.132: atp-req 12266 <0-7> 0xae030001 helios.132> jssmag.209.165: atp-resp 12266: 0 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 1 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 2 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 3 (512) 0xae040000 helios.132> jssmag.209.165: atp- resp 12266: 4 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 5 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 6 (512) 0xae040000 helios.132> jssmag. 209.165: atp-resp * 12266: 7 (512) 0xae040000 jssmag.209.165> helios.132: atp-req 12266 <3,5> 0xae030001 helios.132> jssmag.209.165: atp-resp 12266: 3 (512) 0xae040000 helios .132> jssmag.209.165: atp-resp 12266: 5 (512) 0xae040000 jssmag.209.165> helios.132: atp-rel 12266 <0-7> 0xae030001 jssmag.209.133> helios.132: atp-req * 12267 <0 -7> 0xae030002

Jssmag.209- ը նախաձեռնում է գործարքի ID 12266 հյուրընկալող հելիոսով `պահանջելով մինչեւ 8 փաթեթներ (<0-7>): Գծի վերջում տասնմեկ համարը պահանջի մեջ «userdata» դաշտի արժեքն է:

Հելիոսը պատասխանում է 8 512 բայթ փաթեթներով: Գործարքի անվանումից հետո `` թվանիշը `գործարքի մեջ տալիս է փաթեթի հաջորդականության համարը եւ պարենսի համարը փաթեթում տվյալների քանակն է, բացառությամբ ATP վերնագրի: Փաթեթի 7-ում `*` նշվում է, որ EOM- ի չափը սահմանվել է:

Jssmag.209- ը հարցնում է, որ 3-րդ եւ 5-րդ փաթեթները կրկին փոխանցվեն: Հելիոսը դրանք վերահաստատում է, ապա jssmag.209- ը թողարկում է գործարքը: Վերջապես, jssmag.209- ը նախաձեռնում է հաջորդ հայցը: «*» -ը խնդրանքով ցույց է տալիս, որ XO- ն («ճիշտ մեկ անգամ») չի սահմանվել:

IP պառակտում

Փրոգրված Ինտերնետային դետագագրերը տպագրվում են որպես

(ֆիրմային id : չափը @ օֆսեթ +) (frag id : size @ offset )

(Առաջին ձեւը ցույց է տալիս, որ կա ավելի շատ բեկորներ, երկրորդը, սա վերջին հատվածն է:)

Id- ը մասնիկի ID- ն է: Չափը `հատվածի չափը (բայթերում), բացառությամբ IP գլխի: Օֆսեթը այս հատվածի օֆսեթն է (բայթերում) բնօրինակը datagram- ում:

Փակման տեղեկությունները յուրաքանչյուր հատվածի համար թողարկվում են: Առաջին փակցվածքը պարունակում է ավելի բարձր մակարդակի արձանագրության վերնագիր եւ ֆիրմային տեղեկատվությունը տպագրվում է արձանագրության տվյալներից հետո: Առաջինից հետո բեկորները պարունակում են ոչ ավելի բարձր մակարդակի արձանագրության վերնագիր, եւ փրփուրի տվյալները տպագրվում են աղբյուրի եւ հասցեի հասցեներից հետո: Օրինակ, այստեղ FTP- ի մի մասն է arizona.edu- ից lbl-rtsg.arpa- ին CSNET- ի կապակցությամբ, որը չի երեւում 576 բայտ datagrams- ով:

arizona.ftp-data> rtsg.1170:. 1024: 1332 (308) ack 1 հաղթանակ 4096 (frag 595a: 328 @ 0 +) arizona> rtsg: (frag 595a: 204 @ 328) rtsg.1170> arizona.ftp-data:. 1536 հաղթանակ 2560

Այստեղ նշեք մի քանի բան. Նախ, 2-րդ տողում նշված հասցեները չեն ներառում պորտային համարները: Դա այն է, որ TCP- ի արձանագրության տեղեկատվությունը բոլորի առաջին մասում է, եւ մենք չգիտենք, թե ինչ նավահանգիստ կամ հաջորդականության թվեր են, երբ մենք տպագրում ենք հետագա բեկորները: Երկրորդ, tcp հաջորդականության տեղեկատվությունը առաջին գծում տպագրվում է որպես օգտագործողի տվյալների 308 բայթ, երբ իրականում կա 512 բայ (308 առաջին փրփուրում եւ 204 երկրորդում): Եթե ​​դուք փնտրում եք անցքեր հաջորդականության տարածքում կամ փորձելով համընկնել փաթեթների հետ, ապա դա կարող է հիմարություն անել:

IP- ի փաթեթը չի ցուցադրվում դրոշը նշվում է արգելված (DF) հետ :

Ժամանակահատվածներ

Լռելյայն, բոլոր ելքային տողերը նախորդում են ժամանակացույցի: Ժամանակը ցույց է տալիս ժամացույցի ժամանակի ձեւը

hh: mm: ss.frac

եւ ճիշտ է, ինչպես միջուկի ժամացույցը: Ժամանակահատվածը արտացոլում է, որ միջուկը առաջին անգամ տեսավ փաթեթը: Ոչ մի փորձ չի արվում հաշվարկի ժամանակի միջեւ ընկած ժամանակահատվածի միջեւ, երբ Ethernet ինտերֆեյսը հեռացրել է փաթեթը մետաղից եւ երբ միջուկը ծառայում է «նոր փաթեթի» ընդհատմանը:

ՏԵՍ ՆԱԵՒ

երթեւեկությունը (1C), nit (4P), bpf (4), pcap (3)

Կարեւոր է. Օգտագործեք հրամանատարությունը ( % մարդ ), որպեսզի տեսնեք, թե ինչպես է օգտագործվում հրամանը ձեր որոշակի համակարգչում: