Network Intrusion Detection [3 ed.] 9780735712652, 0735712654

Citation preview

Copyr igh t Copyr igh t © 2 0 0 3 by N e w Ride r s Pu blish in g THI RD EDI TI ON: Sept em ber 2002 All right s reserved. No part of t his book m ay be reproduced or t ransm it t ed in any form or by any m eans, elect ronic or m echanical, including phot ocopying, recording, or by any inform at ion st orage and ret rieval syst em , wit hout writ t en perm ission from t he publisher, except for t he inclusion of brief quot at ions in a review. Library of Congress Cat alog Card Num ber: 2001099565 06 05 04 03 02 7 6 5 4 3 2 1 I nt erpret at ion of t he print ing code: The right m ost double- digit num ber is t he year of t he book's print ing; t he right m ost single- digit num ber is t he num ber of t he book's print ing. For exam ple, t he print ing code 02- 1 shows t hat t he first print ing of t he book occurred in 2002. Print ed in t he Unit ed St at es of Am erica

Tr a de m a r k s All t erm s m ent ioned in t his book t hat are known t o be t radem arks or service m arks have been appropriat ely capit alized. New Riders Publishing cannot at t est t o t he accuracy of t his inform at ion. Use of a t erm in t his book should not be regarded as affect ing t he validit y of any t radem ark or service m ark.

W a r n in g a n d D iscla im e r This book is designed t o provide inform at ion about int rusion det ect ion. Every effort has been m ade t o m ake t his book as com plet e and as accurat e as possible, but no warrant y of fit ness is im plied. The inform at ion is provided on an as- is basis. The aut hors and New Riders Publishing shall have neit her liabilit y nor responsibilit y t o any person or ent it y wit h respect t o any loss or dam ages arising from t he inform at ion cont ained in t his book or from t he use of t he discs or program s t hat m ay accom pany it .

Cr e dit s Publisher David Dwyer

Associat e Publisher St ephanie Wall

Product ion Manager Gina Kanouse

Managing Edit or Krist y Knoop

Senior Acquisit ions Edit or Linda Anne Bum p

Senior Market ing Manager Tam m y Det rich

Publicit y Manager Susan Nixon

Proj ect Edit or Suzanne Pet t ypiece

Copy Edit or Kelli Brooks

I ndexer Larry Sweazy

Manufact uring Coordinat or Jim Conway

Book Designer Louisa Klucznik

Cover Designer Brainst orm Design, I nc.

Cover Product ion Aren Howell

Proofreader Bet h Trudell

Com posit ion Gloria Schurick

D e dica t ion Net work I nt rusion Det ect ion, Third Edit ion is dedicat ed t o Dr. Richard St evens

St ephen Nort hcut t : I can st ill see him in m y m ind quit e clearly at lunch in t he speaker's room at SANS conferences—long blond hair, ponyt ail, t he slight ly fried look of som eone who gives his all for his st udent s. I rem em ber t he scores from his com m ent form s. Richard St evens was t he best inst ruct or of us all. I know he is gone and yet , every couple days, I reach for his book TCP/ I P I llust rat ed, Volum e 1, usually t o glance at t he packet headers inside t he front cover. I am so t hankful t o own t hat book; it helps m e underst and I P and TCP, t he net work prot ocols t hat drive our world. I n t hree weeks or so, I will t each TCP t o som e four hundred st udent s. I am so scared. I cannot fill his shoes, not even close, but t he knowledge m ust cont inue t o be passed on. I can't st ress " m ust " enough; t here is no m agic product t hat can do int rusion det ect ion for you. I n t he end, every analyst needs a basic underst anding of how I P works so t hey will be able t o det ect t he anom alies. That was t he gift Dr. St evens left each of us. This book builds upon t hat foundat ion! Judy Novak: Of all t he influences in t he field of securit y and t raffic analysis, none has been m ore profound t han t hat of t he lat e Dr. Richard St evens. He was a prolific and accom plished aut hor. The book I 'm m ost fam iliar wit h is m y dogeared, garlic saucest ained copy of TCP/ I P I llust rat ed, Volum e 1. I t is an absolut e m ast erpiece because he is t he ult im at e aut horit y on TCP/ I P and Unix, and he had t he rare abilit y t o m ake t he subj ect s coherent . I know several of t he inst ruct ors at SANS consider t his work t o be t he " bible" of TCP/ I P. I once had t he opport unit y t o be a st udent in a course he t aught for SANS, and I t hink I sat wit h m out h agape in reverence of som eone wit h such knowledge. Last sum m er, he agreed t o edit a course I had writ t en for SANS in elem ent ary TCP/ I P concept s. This was t he equivalent of having Shakespeare crit ically review a grocery list . I carry his book wit h m e everywhere, and I will not soon forget him .

Ack n ow le dgm e n t s St ephen Nort hcut t : The net work det ect s and analyt ical insight s t hat fill t he pages of t his book are cont ribut ions from m any analyst s all over t he world. You and I owe t hem a debt of t hanks; t hey have given us a great gift in m aking what was once m yst erious, a known pat t ern. I t hank everyone who has served on, or cont ribut ed t o, t he I ncident s.org t eam . You have found m any new pat t erns, helped m inim ize t he dam age from a num ber of com prom ised syst em s, and even m anaged t o t each a bit of int rusion det ect ion along t he way. Good work! I ncident handlers would be of lit t le purpose if people weren't report ing at t acks. The folks who cont ribut e dat a t o dshield.org are m aking a real difference. You showed t hat it was possible t o share at t ack inform at ion and analysis and t hat bit by bit we would get sm art er, bet t er able t o underst and exploit s and probes. Judy Novak, t hank you for working wit h m e on t his proj ect . Your effort s and knowledge are t he reason for t he book's success. I t ruly appreciat e t he work our t echnical edit ors, Karen Kent Frederick and David Heinbuch, have done t o cat ch t he errors t hat can creep in while you are working lat e int o t he night , or from an airplane. Suzanne Pet t ypiece, t hank you for your pat ience and organizat ion in t he busiest m ont hs of m y ent ire life. A big t hanks t o Linda Bum p for working wit h us t o keep t he proj ect on schedule! I want t o t ake t his opport unit y t o express m y appreciat ion t o Alan and Marsha Paller for friendship, support , encouragem ent , and guidance. Kat hy and Hunt er, t hank you again for t he love and support in a writ ing cycle. Kat hy, I especially t hank you for being willing t o quit your j ob t o help m e keep all t he plat es spinning. I love you. " But if any of you lacks wisdom , let him ask of God, who gives t o all m en generously and wit hout reproach, and it will be given t o him ." Jam es 1: 5 Any wisdom or underst anding I have is a gift from t he Lord Jesus Christ , God t he All Might y, and t he credit should be given t o Him , not t o m e. I hope you enj oy t he book and it serves you well! Judy Novak: Many t hanks t o St ephen Nort hcut t for his t ireless effort s in educat ing t he world about securit y and encouraging m e t o j oin him in his effort s. His guidance has lit erally changed m y life and t he rewards and opport unit ies from his influence have been plent iful. While t he words t o express m y t hanks seem anem ic, t he grat it ude is t ruly heart felt .

I 'd like t o t hank t he wonderfully wise t echnical edit ors David Heinbuch and Karen Kent Frederick for t heir pat ient and ast ut e feedback. They are t he blessed souls who save m e from t ot al em barrassm ent ! Also, I 'd like t o ext end special t hanks t o Paul Rit chey, who edit ed t he Snort chapt ers for t echnical accuracy. He whipped out t he feedback wit h speed and insight . Finally, last , but never least , I 'd like t o t hank m y fam ily—Bob and Jesse—for leaving m e alone long enough when I needed t o work on t he book, but gent ly nudging m e t o t ake a break when at rophy set in. There is real danger in being left alone t oo long!

I n t r odu ct ion Our goal in writ ing Net work I nt rusion Det ect ion, Third Edit ion has been t o em power you as an analyst . We believe t hat if you read t his book cover t o cover, and put t he m at erial int o pract ice as you go, you will be ready t o ent er t he world of int rusion analysis. Many people have read our books, or at t ended our live class offered by SANS, and t he light s have gone on; t hen, t hey are off t o t he races. We will cover t he t echnical m at erial, t he workings of TCP/ I P, and also m ake every effort t o help you underst and how an analyst t hinks t hrough dozens of exam ples. Net work I nt rusion Det ect ion, Third Edit ion is offered in five part s. Part I , " TCP/ I P," begins wit h Chapt er 1, ranging from an int roduct ion t o t he fundam ent al concept s of t he I nt ernet prot ocol t o a discussion of Rem ot e Procedur e Calls ( RPCs) . We realize t hat it has becom e st ylish t o begin a book saying a few words about TCP/ I P, but t he syst em Judy and I have developed has not only t aught m ore people I P but a lot m ore about I P as well—m ore t han any ot her syst em ever developed. We call it " real TCP" because t he m at erial is based on how packet s act ually perform on t he net work, not t heory. Even if you are fam iliar wit h I P, give t he first part of t he book a look. We are confident you will be pleasant ly surprised. Perhaps t he m ost im port ant chapt er in Part I is Chapt er 5, " St im ulus and Response." Whenever you look at a net work t race, t he first t hing you need t o det erm ine is if it is a st im ulus or a response. This helps you t o properly analyze t he t raffic. Please t ake t he t im e t o m ake sure you m ast er t his m at erial; it will prevent analysis errors as you m ove forward. Tip Whenever you look at a net work t race, t he first t hing you need t o det erm ine is if it is a st im ulus or a response.

The book cont inues in Part I I , " Traffic Analysis" wit h a discussion of t raffic analysis. By t his, we m ean analyzing t he net work t raffic by considerat ion of t he header fields of t he I P and higher prot ocol fields. Alt hough ASCI I and hex signat ures are a crit ical part of int rusion det ect ion, t hey are only t ools in t he analyst 's t ool belt . Also in Part I I , we begin t o show you t he im port ance of each field, how t hey are rich t reasures t o underst anding. Every field has m eaning, and fields provide inform at ion bot h about t he sender of t he packet and it s int ended purpose. As t his part of t he book com es t o a close, we t ell you st ories from t he perspect ive of an analyst seeing net work pat t erns for t he first t im e. The goal is t o help you prepare for t he day when you will face an unknown pat t ern. Alt hough t here are t im es a net work pat t ern is so obvious it alm ost scream s it s m essage, m ore oft en you have t o search for event s of int erest . Som et im es, you can do t his wit h a well- known signat ure, but equally oft en, you m ust search for it . Whenever at t ackers writ e soft ware for denial of service, or exploit s, t he soft ware

t ends t o leave a signat ure t hat is t he result of craft ing t he packet . This is sim ilar t o t he way t hat a bullet bears t he m arks of t he barrel of t he gun t hat fired it , and expert s can posit ively ident ify t he gun by t he bullet . I n Part I I I of t he book, " Filt ers/ Rules for Net work Monit oring" we build t he skills t o exam ine any field in t he packet and t he knowledge t o det erm ine what is norm al and what is anom alous. I n t his sect ion, we pract ice t hese skills bot h wit h TCPdum p and also Snort . I n Part I V, we consider t he larger fram ework of int rusion det ect ion. We discuss where you should place sensors, what a console needs t o support for dat a analysis, and aut om at ed and m anual response issues t o int rusion det ect ion. I n addit ion, t his sect ion helps arm t he analyst wit h inform at ion about how t he int rusion det ect ion capabilit y fit s in wit h t he business m odel of t he organizat ion. Finally, t his book provides t hree appendixes t hat reference com m on signat ures of well- known reconnaissance, denial of service, and exploit scans. We believe you will find t his t o be no fluff, packed wit h dat a from t he first t o t he last page. Net work I nt rusion Det ect ion, Third Edit ion has not been developed by professional t echnical writ ers. Judy and I have been working as analyst s since 1996 and have faced a num ber of new pat t erns. We are t hankful for t his opport unit y t o share our experiences and insight s wit h you and hope t his book will be of service t o you in your j ourney as an int rusion analyst .

Pa r t I : TCP/ I P 1 I P Concept s 2 I nt roduct ion t o TCPdum p and TCP 3 Fragm ent at ion 4 I CMP 5 St im ulus and Response 6 DNS

Ch a pt e r 1 . I P Con ce pt s

As you read t his chapt er, it will becom e apparent t hat you belong in one of t wo cat egories: t he beginner cat egory or t hat of t he seasoned vet eran. The I nt ernet Prot ocol ( I P) is a large and pot ent ially int im idat ing t opic t hat requires a gent le int roduct ion for uninit iat ed beginners so as not t o overwhelm t hem wit h foreign acronym s, det ails, and concept s. Therefore, t he purpose of t his first chapt er is t o expose newcom ers t o t erm s, concept s, and t he ever- present acronym s of I P. The suit e of prot ocols covered here is m ore com m only known as Transm ission Cont rol Prot ocol/ I nt ernet Prot ocol ( TCP/ I P) . These prot ocols are required t o com m unicat e bet ween host s on t he I nt ernet —t he worldwide infrast ruct ure of net worked host s. I ndeed, com m unicat ion prot ocols ot her t han TCP/ I P exist ( for inst ance, AppleTalk for Apple com put ers) . These prot ocols are t ypically found on int ranet s, where associat ed host s t alk on a privat e net work. Most I nt ernet com m unicat ions require TCP/ I P, which is t he st andard for global com m unicat ions bet ween host s and net works. Those seasoned vet eran readers who dabble in TCP/ I P daily m ight be t em pt ed t o skip t his chapt er. Even so, you should give it a quick skim . I f you ever need t o explain a concept about I P ( perhaps t o t he individual who signs off on your pay raise or bonus, for exam ple) , you m ight find t his chapt er's approach useful. Those of you who are get t ing your feet wet in t his area will cert ainly benefit from t his int roduct ion. This is an around- t he- world int roduct ion t o TCP/ I P present ed in a single chapt er. Many of t he t opics discussed in t his int roduct ory chapt er are covered in m uch great er det ail and com plexit y in upcom ing chapt ers; t hose chapt ers cont ain t he core cont ent , but you need t o be able t o peel away t he t heoret ical skin t o underst and t hem . Specifically, t his chapt er covers t he following t opics: z

The TCP/ I P I nt ernet m odel. This sect ion exam ines t he foundat ions of com m unicat ions over t he I nt ernet , specifically com m unicat ions m ade possible

by using a com m on m odel known as t he TCP/ I P I nt ernet m odel. z

z

z

z

z

Packaging of dat a on t he I nt ernet . This sect ion reviews t he encapsulat ion of dat a t o be sent t hrough different legs of a j ourney t o it s dest inat ion. Physical and logical addresses. This sect ion highlight s t he different ways t o ident ify a com put er or host on t he I nt ernet . TCP/ I P services and port s. This sect ion explores how host s com m unicat e wit h each ot her for different purposes and t hrough different applicat ions. Dom ain Nam e Syst em . This sect ion focuses on t he im port ance of host nam es and I P num ber t ranslat ions. Rout ing. This sect ion explains how dat a is direct ed from t he sending com put er t o t he receiving com put er.

Th e TCP/ I P I n t e r n e t M ode l Com put er users oft en want t o com m unicat e wit h anot her com put er on t he I nt ernet for som e purpose or anot her ( t o view a web page on a rem ot e web server, for inst ance) . A response from a web server can seem alm ost inst ant aneous, but a lot of processes and infrast ruct ures act ually support t his seem ingly t rivial act behind t he scenes. La ye r s Figure 1.1 shows a logical roadm ap of som e of t he processes involved in host - t ohost com m unicat ions. You begin t he process of downloading a web page in t he box labeled " Web browser." Before your request t o see a web page can get t o t he web server, your com put er m ust package t he request and send it t hrough various processes and layers. Each layer represent s a logical leg in t he j ourney from t he sending com put er t o t he receiving com put er. Aft er t he sending com put er packages t he dat a t hrough t he different layers, it is delivered t o t he receiving com put er over t he I nt ernet . The receiving com put er unwraps t he dat a layer by layer. An individual layer get s t he dat a int ended for it and passes t he rem ainder of t he m essage t o upper layers. Figu r e 1 .1 . Th e TCP/ I P I n t e r n e t m ode l.

Alt hough discussed in m ore det ail lat er in t his chapt er, it is im port ant now t o briefly look at each layer. The following four layers com prise t he TCP/ I P I nt ernet m odel: z

z

Applicat ion layer. The applicat ion layer is t he t opm ost layer ( t he request for a web page in t he preceding exam ple) . Soft ware on t he sending and receiving com put ers support s t he im plem ent at ion of t he applicat ion ( t he web browser and web server, for inst ance) . Transport layer. Below t he applicat ion layer lays t he t ransport layer. This layer encom passes m any aspect s of how t he t wo host s will com m unicat e. This t ransport layer is oft en concerned wit h providing reliabilit y over ot her inherent ly unreliable layers. Two t ransport layers prot ocols will be covered: TCP, which is referred t o as a reliable prot ocol because m echanism s ensure dat a delivery, and User Dat agram Prot ocol ( UDP) , which m akes no prom ise of reliable delivery. I n t his exam ple applicat ion, TCP is required because of t he unaccept abilit y of dat a loss.

z

z

Net work layer. Below t he t ransport layer is t he net work layer, which is responsible for m oving t he dat a from t he source com put er t o t he dest inat ion com put er ( t he web server in t his case) , oft en one hop or leg of t he j ourney at a t im e. This hop is bet ween a com put er and a rout er or a rout er and a rout er, but it ult im at ely t akes t he dat a closer in rout ing space t o it s dest inat ion. Link layer. The bot t om layer is t he link layer, which is t he com ponent t hat t akes care of com m unicat ions from a host t o t he physical m edium on which it resides. I n t his case, t hat com ponent is Et hernet . This layer is concerned wit h receiving and sending dat a from t he host over a specific int erface t o t he net work.

D a t a Flow Look at Figure 1.1 again. I n t heory, t he dat a flow act ivit y is t his: The request for a web page " descends" t he sender's layers, oft en referred t o as t he TCP/ I P st ack. I t get s direct ed t o t he dest inat ion com put er and " ascends" it s TCP/ I P st ack. The vert ical arrows bet ween layers represent t he up and down flow on t he sam e com put er. The horizont al arrows bet ween com put ers signify t hat each layer t alks t o it s " peer" layer on t he com m unicat ing host . The t wo com put ers do not direct ly int eract wit h each ot her, per se. When t he request descends t he sending com put er's TCP/ I P st ack, it is packaged in such a m anner t hat each layer has a m essage for it s count erpart layer, and so t hey appear t o be t alking direct ly. This concept is quit e im port ant and crucial t o underst anding t his chapt er and t he TCP/ I P m odel, in general. Therefore, it is im port ant t o reit erat e t he poignant point s and elaborat e on t erm inology. The t erm TCP/ I P st ack is used t o denot e t he layered st ruct ure of processing a TCP/ I P request or response. A process known as encapsulat ion does t he im plem ent at ion of t he layering. This m eans t hat dat a on t he sender's host get s wrapped wit h ident ifying inform at ion t o assist t he receiving host in parsing t he received m essage layer by layer. Each layer on t he sending host adds it s own header, and t he receiving host reverses t he process by exam ining t he m essage, st ripping it of it s header, and direct ing it t o t he appropriat e layer. This process is repeat ed for t he higher layers unt il t he dat a reaches t he upperm ost layer, which finally processes t he web page request . When t he response is sent back, t he ent ire process is repeat ed; now t he web server host packages t he dat a t o be sent , it is delivered and received, and t he web browser host st rips t he received m essage t o pass t o t he applicat ion layer support ing t he web browser.

Pa ck a gin g ( Be yon d Pa pe r or Pla st ic) At a very granular level, dat a exchanged bet ween host s m ust be bundled in som e kind of st andard form at . A host is a generic t erm t hat can reference a workst at ion on your desk, a rout er, or a web server t o nam e j ust a few exam ples. The im port ant dist inct ion is t hat t hese com put ers are connect ed t o a net work capable of t ransport ing dat a t o and from t he com put er. I n t he generic sense, t he packaging of associat ed dat a is called a packet . The problem in t erm inology arises because t his dat a package is labeled different ly at various layers of com m unicat ion bet ween t he source applicat ion and t he dest inat ion applicat ion locat ed on different host s. This sect ion discusses som e of t he key concept s relat ed t o dat a packaging, including bit s, byt es, packet s, dat a encapsulat ion, and int erpret at ion of t he layers. Bit s, Byt e s, a n d Pa ck e t s The at om of com put ing is a bit , a single st orage locat ion t hat has a value of eit her

0 or 1 ( also known as binary) . Alt hough succinct and com pact , you cannot act ually st ore or convey a lot of inform at ion wit h a single bit , so bit s are grouped int o clum ps of eight . A unit of eight bit s is a byt e ( or oct et , if you prefer) . Eight t im es a very sm all am ount of inform at ion is st ill pret t y sm all, but an oct et can cont ain an Am erican St andard Code for I nform at ion I nt erchange ( ASCI I ) charact er, such as t he let t er a or a com m a ( ,) . I t can also hold a large int eger num ber, as high as 255 ( 2 8 - 1) .

Bit s, Byt e s, a n d Bin a r y Figure 1.2 shows a byt e. Because t his discussion is focusing on bit s, binary is t he language used— t he language of 0s and 1s. Each bit is represent ed as a power of 2, t he base of binary. Not ice t hat a byt e spans powers of 2 from 2 0 t hrough 2 7 . I f all bit s have a value of 0, t he byt e is obviously 0. Now, im agine t hat all bit s are 1s. Add up all t he individual bit values, st art ing wit h t he sm allest value ( 2 0 = 1, any base wit h an exponent of 0 is 1) ; you will have 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128. The t ot al value is 255, and t hat is t he m axim um value t hat a given byt e can have. This value is exam ined lat er when t he discussion t urns t o I P addresses.

Figu r e 1 .2 .

You j ust saw an exam ple of how binary- t o- decim al conversion is done. I f you are given a byt e of dat a, j ust re- creat e t his byt e wit h t he appropriat e powers of 2 and t heir associat ed decim al values. Any bit t hat is set is assigned t he accom panying decim al value of t hat bit . Then, j ust t ot al up all t he decim al values; voila, t he conversion is done. This is not really rocket science aft er all. Mult iple byt es, or oct et s, are grouped t oget her for shipping across a net work by packaging t hem int o packet s. Figure 1.3 shows one of t he great t rut hs of net working: An overhead cost accrues when slinging packet s around t he net work.You have t o go t hrough a lot of t rouble t o package your cont ent for shipping across a net work and t hen t o unwrap it when it get s t o t he ot her side ( and even m ore t rouble, of course, t o finish t he j ob wit h a t am per- proof seal) . A field known as t he cyclical redundancy check ( CRC) , or checksum , is used t o

validat e t hat t he fram e ( t he nam e given t o t he packet on t he wire) has not been dam aged or corrupt ed in t ransit . Figu r e 1 .3 . Por t r a it of a pa ck e t .

Like an envelope addressed for m ailing, I P packet s need t o include t he addresses of bot h t he sending and receiving host s ( see Figure 1.3) . I f you live in a house wit h a st reet address, you can t hink of t hat as your hardware address, t he address assigned t o your house. I n net working, at least wit h Et hernet net works, t his is analogous t o a net work int erface card's ( NI C) Media Access Cont roller ( MAC) address. This hardware address is assigned t o t he NI C when t he card is const ruct ed. The MAC address is 48 bit s long, which m eans it can hold a very large num ber ( 2 48 - 1) . The " Addresses" sect ion lat er in t his chapt er discusses t he differences bet ween MAC addresses and I P addresses. To creat e a fram e, which is t he nam e t he packet acquires when t ransm it t ed on physical m edia, you const ruct t he packet using various prot ocol layers and t hen include t he physical inform at ion. Finally, t he fram e is placed on t he net working m edium by t he NI C. The fram e has a fram e header of 14 byt es, wit h fields such as t he source and dest inat ion MAC addresses, fram e dat a t hat can vary in lengt h, and a t railer of 4 byt es t hat represent s t he CRC. En ca psu la t ion Re visit e d Figure 1.4 represent s t he concept of t he layered packaging configurat ion. Different layers of prot ocols t heoret ically " t alk" t o like layers of prot ocols on t he source and dest inat ion host s. The layers are st acked at op one anot her— hence, t he origin of t he t erm " TCP/ I P st ack." At each layer of t he st ack, t he packet consist s of a header of it s own and dat a, som et im es known as t he payload. All t he encapsulat ion is done for t he purpose of sending som e kind of cont ent , but t he encapsulat ion requires different header inform at ion at different levels in it s j ourney from source t o dest inat ion. Figu r e 1 .4 . On e la ye r 's h e a de r is a not h e r la ye r 's da t a .

Suppose t hat you have a m essage or ot her cont ent t o send. I t is first collect ed by t he applicat ion, which could be a program such as t elnet or elect ronic m ail; t hese TCP applicat ions are discussed in m ore det ail in t he sect ion " I P Prot ocols." The TCP packet is known as a TCP segm ent and includes t he TCP header and TCP dat a. I f t his were UDP, t he packet would be known as a dat agram , which is confusing because it is redundant wit h t he nam e at t he I P layer. At t his point , t he TCP segm ent is handed down from t he TCP layer of t he TCP/ I P st ack t o t he I P layer. The I P layer prepends ( t hat m eans appends at t he front ) header inform at ion t o t he TCP segm ent and becom es known as an I P dat agram . Really, t he TCP header and dat a becom e invisibly enm eshed as dat a for t he I P dat agram , which has it s own header. The I P dat agram is delivered t o t he link layer of t he TCP/ I P st ack, and it is known as a fram e. The link layer prepends t he fram e header t o t he I P dat agram t o carry it across t he physical m edium , such as Et hernet . The process is repeat ed in reverse when t he fram e arrives at t he dest inat ion host and all headers are st ripped away and passed t o t he proper upper- layer prot ocols. Each layer of t he TCP/ I P st ack wit h it s em bedded m essage converses wit h t he sim ilar layer of t he receiving host . I n t e r pr e t a t ion of t h e La ye r s Wit h all t he layering going on, t he bot t om line is t hat you have a bunch of adj acent 0s and 1s. How do you know how t o int erpret t hem ? Suppose t hat you are looking at t he I P header; how do you know what kind of em bedded prot ocol you will find following it ? Surely t hat m ust be known t o properly int erpret t he prot ocol. The t erm prot ocol is m eant t o denot e a set of agreed upon rules or form at s. Each prot ocol ( such as I P, TCP, UDP, and I CMP) has it s own layout s and form at s. Figure 1.5 shows an exam ple of t he organizat ion of t he I P header. You can see t hat a cert ain num ber of bit s are allocat ed for each field in t he header. A Prot ocol field ident ifies t he em bedded prot ocol. Each row t hat you see in t he I P header is 32 bit s ( 0 t hrough 31, inclusive) , which m eans four ( 8- bit ) byt es. To com plicat e m at t ers a lit t le, count ing st art s wit h 0 when t alking about bit and byt e locat ions.

The first row represent s byt es 0 t hrough 3; t he second row represent s byt es 4 t hrough 7; and t he t hird row represent s byt es 8 t hrough 11. Not ice t hat t he circled Prot ocol field is in t he t hird row. The preceding t im e- t o- live ( TTL) field is 1 byt e long, which m akes it t he 8t h byt e; and t he Prot ocol field, which is also 1 byt e long, represent s t he 9t h byt e. This m eans t hat t he 9t h byt e ( act ually, it 's t he 10t h byt e, but rem em ber count ing st art s at 0) is exam ined t o find t he em bedded prot ocol. The point is t hat m ost packet s at t heir respect ive levels are posit ional; fields can be discovered by going t o known displacem ent s in t he packet . Figu r e 1 .5 . Posit ion a l la you t s.

Now t hat you have count ed your way t o t he Prot ocol field, what is it and what does it do? The value in t his field t ells you what prot ocol is found in t he em bedded dat a. Suppose t hat t he value you find in t his byt e is 17. You m ight find t he prot ocol value expressed in hexadecim al. A hexadecim al 11 is t he sam e as a decim al 17. This m eans t hat a UDP packet is em bedded aft er t he I P header. A value of 6 m eans t hat t he em bedded packet is TCP, and a value of 1 m eans t hat it is I nt ernet Cont rol Message Prot ocol ( I CMP) .

Ba se 1 6 , H e x a de cim a l Okay, so you have learned t hat binary is base 2 and is m ade up of 0s and 1s. This is t he num bering syst em used by com put ers t o represent dat a. So, why com plicat e t he m at t er wit h anot her ent irely new num bering syst em , base 16 ( or hexadecim al) ? The real dilem m a is t hat it t akes a lot of bit s t o represent any sizable num ber and, t herefore, binary becom es very unwieldy very soon. Hexadecim al assist s in referencing binary num bers in a m ore abbreviat ed not at ion. You can replace 4 binary bit s wit h 1 hexadecim al charact er ( 2 4 = 16) . Consider, for exam ple, t he I P header prot ocol field; it is 8 bit s. That can be convert ed int o 2 hex charact ers. A decim al 17 in t he prot ocol field, as m ent ioned earlier, m eans t hat t he em bedded prot ocol is UDP. How do you go from a decim al 17 t o a hexadecim al 11?

27 26 25 24 0 0 0 1

23 22 21 20 0 0 0 1

The binary powers of t he 8 bit s are shown. To arrive at 17, you need t o have t he bit corresponding t o 16 ( or 2 4 ) set t o 1, and t he bit corresponding t o 1 ( 2 0 ) set t o 1—t hat is, 16 + 1 = 17. These have been grouped as t wo hex digit s, t wo 4- bit clum ps. The 4 bit s ( or hex charact er) t hat are left m ost ( also known as high- order or m ost significant bit s) have a value of 0001. Likewise, t he 4 bit s t hat are right m ost ( also known as low- order or least significant bit s) have a value of 0001. Each hex charact er represent s values of 0 t hrough 15. And each of t hese has a low- order bit of 1 set ( 2 0 ) , and so we arrive at t he value of 11 hexadecim al ( also known as 0x11, in which t he 0x dist inguishes t his as hex, not decim al) .

Addr e sse s Most likely, you have heard t he t erm I P address. But , what does it really represent and what does it really do? And, exact ly how do host s address each ot her? These are som e of t he t opics covered in t his sect ion. Ph ysica l Addr e sse s, M e dia Acce ss Con t r olle r Addr e sse s You can scour t he headers of I P packet s looking for physical layer MAC addresses unt il you t urn blue, and you will not find t hem . MAC addresses do not m ean anyt hing t o I P, which uses logical addresses; t hey are not part of t he prot ocol. For all int ent s and purposes, t hey m ay as well not exist . By t he sam e t oken, physical MAC addresses are how t he Et hernet card int erfaces wit h t he net work. The Et hernet card does not know a single t hing about I P, I P headers, or logical I P addresses. So, you are faced wit h t he signat ure line of Cool Hand Luke: " What we have here is a failure t o com m unicat e." Clearly, if t hings are going t o work, an operat ion process is required t hat facilit at es t he correspondence bet ween logical I P and physical MAC addresses. Do you know t he I P address of your deskt op com put er? I f you don't , you are not really one down at all; it is absolut ely norm al not t o know it . I t is norm al for several reasons, one being t hat in t hese days m ost of you don't even own or even get t o keep t he sam e I P address. I P address space is a precious com m odit y. When you connect t o t he net work, m any of you are loaned an address for t hat session, or possibly longer by an I nt ernet service provider ( I SP) or net work service provider via applicat ions, such as Dynam ic Host Configurat ion Prot ocol ( DHCP) .

Le a sin g a n I P N u m be r : D yn a m ic H ost Con figu r a t ion Pr ot ocol DHCP is a prot ocol t hat perm it s dynam ic assignm ent of I P num bers. This replaces t he labor- int ensive process of I P address m anagem ent , in which every host is configured wit h a st at ic I P num ber assigned t o it . DHCP allows t he cent ralizat ion and aut om at ion of t he I P assignm ent process. Host s are leased an I P num ber for a given am ount of t im e, and t his m akes t he process of m anaging and adm inist ering large net works m ore efficient . This is good for t he net work adm inist rat or, but m akes t he securit y adm inist rat or's j ob m ore com plicat ed ( for exam ple, when som e I P num ber and associat ed t em porary owner have t o be chased down for quest ionable act ivit y) . Exact ly how m any possible I P num bers are t here? The exact num ber is 2 32 ( because t he address is com prised of 32 bit s) , which is a num ber higher t han 4 billion. But , every single I P num ber is not available; reserved ranges decrease t he possible num bers. Wit h t he explosive growt h of t he I nt ernet worldwide, t he sad realizat ion has dawned t hat t he I P addresses are being rapidly deplet ed. What are som e rem edies for t he address deplet ion? First , a part icular sit e can use DHCP and assign I P num bers t em porarily for t he durat ion of t heir use. This m eans t hat not all host s will be act ive at any given t im e and a sm aller pool of possible I P num bers is required. The ot her rem edy is som et hing known as reserved privat e addresses. The governing body of t he I nt ernet , t he I nt ernet Address Num bers Aut horit y ( I ANA) , has set aside blocks of I P addresses t o be used for int ernal addresses only. For inst ance, t he 192.168 and 172.16 subnet s are t o be used for host s t alking wit hin a part icular net work. This t raffic should not leave t he sit e's gat eway. This allows a sit e wit h an insufficient num ber of I P addresses t o use t hese Class B net work addresses for int ernal purposes and t o save t he assigned I P addresses for ot her purposes. Okay, go ahead and sm irk now; som e of you did know your I P address. That is good. However, do you know your host 's MAC address by heart ? The answer would m ost likely be " no," because alm ost no one knows his MAC address. There are several reasons for t his, but t he prim ary one is t hat a 48- bit address wit h no provisions for hum an m em orizat ion is hard t o lock int o t he brain. The Address Resolut ion Prot ocol ( ARP) enables you t o resolve t he t ranslat ion of physical MAC addresses t o logical I P addresses. ARP is not an I P prot ocol per se; it is t he process of sending an Et hernet fram e t o all syst em s on t he sam e net work segm ent . This is known as a broadcast . I f a m essage is a broadcast m essage, it is sent t o all t he m achines on part of or t he ent ire net work. A point wort h em phasizing is t hat ARP is for locally at t ached host s only on t he sam e net work; t his cannot be done bet ween host s on different net works.

The source host broadcast s t he ARP request , and t hen presum ably t he dest inat ion host picks it up and replies wit h it s MAC address. During t his t ransact ion, bot h t he source and dest inat ion host , and any list ening host s on t he net work, cache ( or save) what t hey have learned about t he ot her host , t hereby st oring t he I P and MAC addresses. This st orage cut s down on t he num ber of new ARP request s required. Ult im at ely, on t he sam e net work segm ent , t he com m unicat ions will occur bet ween MAC addresses and not I P addresses. They m ight begin as a TCP/ I P t ransact ion wit h t wo host s com m unicat ing bet ween t he sam e layers of TCP/ I P, but when t he act ual delivery occurs, com m unicat ion is bet ween t wo host s' MAC addresses. Why are MAC addresses so huge? Aft er all, 48 bit s is a lot of address space. The idea was t hat t hey would be unique for all t im e and space! That sounds good if you say it real fast , but fut ure plans are t o expand t his value t o 128 bit s t o accom m odat e it s current lim it at ions in allowing each NI C m anufact urer t o have a unique vendor code em bedded in t he MAC address. Logica l Addr e sse s, I P Addr e sse s An I P address has 32 allocat ed bit s t o ident ify a host . This 32- bit num ber is expressed as four decim al num bers separat ed by periods ( for exam ple, 192.168.5.5) . These are not j ust random or sequent ial assignm ent s. The init ial port ion of t he I P num ber t ells som et hing about t he size of t he net work on which t he host resides. The rem ainder of t he I P num ber dist inguishes host s on t hat net work. Addresses are cat egorized by class; classes t ell how m any host s are in a given net work or how m any bit s in t he I P address are assigned for t he unique host s in a net work ( see Table 1.1) . A grouping known as Class A addresses assigns t he init ial 8 bit s for a net work port ion of t he address, for exam ple, and t he final 24 bit s for t he host port ion of t he address. Because 24 bit s have been allocat ed for t he host s, m ore t han 16 m illion ( 2 24 - 1) host s can possibly be in t he net work. An exam ple of a Class A net work is t he 18.0.0.0 t hrough 18.255.255.255, I P space assigned t o Massachuset t s I nst it ut e of Technology.

Ta ble 1 .1 . 3 2 Bit s for I P Addr e ss Spa ce

Cla ss

N e t w or k Bit s

H ost Bit s

N u m be r of H ost s

A

8

24

16 m illion+

B

16

16

65,000+

C

24

8

255

The I P address classes range from Class A addresses t o Class E. Classes A, B, and C are unicast addresses; when you send a packet t o t hem , presum ably you are addressing a single m achine. Class D is known as a m ult icast address used t o com m unicat e wit h a designat ed set of host s. Class E is reserved for experim ent al

use. Table 1.2 shows t he address range associat ed wit h each class.

Ta ble 1 .2 . Addr e ss Cla sse s a n d I P Ra n ge s

Cla ss

Be gin n in g I P

En din g I P

A

0.0.0.0

127.255.255.255

B

128.0.0.0

191.255.255.255

C

192.0.0.0

223.255.255.255

D

224.0.0.0

239.255.255.255

E

240.0.0.0

247.255.255.255

H ou se Ru le s of CI D R You m ight hear a new t erm , classless int er- dom ain rout ing ( CI DR) t o refer t o addresses. For t he longest t im e, addresses were part of a part icular class and t hat m eant your net work was allocat ed eit her 16 m illion+ , 65,000+ , or 255 host s. The m ost com m on sit uat ion was net works t hat required bet ween 255 and 65,000 host s. Because m any of t hese sit es were allocat ed Class B net works, m any I P num bers went unassigned. Given t hat I P num bers are finit e com m odit ies, a rem edy was needed t o allocat e net works wit hout class const raint s. CI DR assigns net works, not on 8- bit boundaries, but on single- bit boundaries. This allows a sit e t o receive t he appropriat e num ber of I P num bers, and t hus reduces wast e. CI DR uses a unique not at ion t o designat e t he range of host s assigned t o a sit e. I f you want t o specify t he 192.168 address range in CI DR, it would look like 192.168/ 16. The first part of t he not at ion is t he decim al represent at ion of t he bit pat t ern allocat ed t o t he net work. I t is followed by a slash and t hen t he num ber of bit s t hat represent t he net work port ion of t he address. This exam ple is t he sam e as a Class B net work, but it can be m odified easily enough t o represent sm aller net works. Su bn e t M a sk s Anot her concept you need t o be aware of is som et hing known as t he subnet m ask. This m ask inform s a given com put er syst em how m any bit s in it s I P address have been relegat ed t o t he net work and how m any t o t he host . Each bit t hat is a net work bit is " m asked" wit h a 1. A Class A address, for inst ance, has 8 net work bit s and 24 host bit s. I n binary, t he 8 consecut ive bit s ( all wit h a value of 1) t ranslat e t o a decim al 255. The subnet m ask is t hen designat ed as 255.0.0.0. Ot her classes have ot her subnet m asks. A Class B net work has a st andard subnet

m ask of 255.255.0.0, and a Class C net work has a st andard subnet m ask of 255.255.255.0. Why is t his needed if you can t ell what class and how m any bit s have been reserved for t he net work by exam ining t he I P address? Som e net work adm inist rat ors subdivide t heir net works. For inst ance, a Class C net work could be divided int o four individual subnet s by assigning an appropriat e subnet m ask.

Se r vice Por t s This sect ion is a " bit " easier. TCP and UDP have 16- bit port num ber fields in t heir respect ive header fields. This m eans t hey can have as m any as 65,536 different port s, or services, and t hey are num bered from 0 t o 65,535. One very im port ant point t o regist er in your long- t erm m em ory is t hat even t hough a service is usually locat ed at it s assigned port num ber, not hing guarant ees t his as t rue. Telnet , for inst ance, is alm ost universally found on TCP port 23. There is not hing st opping your nonconform ist side from offering it at port 31337. And, what bet t er way for a hacker who has broken int o a com put er t o hide his t racks t han by offering a service at an unexpect ed port ? I f a hacker were t o run t elnet at som e highnum bered port rat her t han port 23, it would m ake his unaut horized connect ion m ore difficult t o find and ident ify. Any service can be run at any port . On t he ot her hand, if you want t o net work wit h ot her host s, it is best t o follow t he st andards. For UNI X host s, t he / et c/ services file can be an excellent resource t o m at ch TCP or UDP port num bers wit h t he expect ed, or well- known, services likely t o be offered at t hat port num ber. You see som e very com m on port num bers and service exam ples from t he / et c/ services file. An excerpt here shows you t he form at of t he file and t he associat ed services. You see t hat a service known as dom ain ( Dom ain Nam e Service, or DNS) can be offered on bot h TCP and UDP. This is unusual, but not abnorm al; m ost services are offered on eit her TCP or UDP, but t here are som e except ions ( such as DNS) .

ftp telnet smtp domain domain

21/tcp 23/tcp 25/tcp 53/udp 53/tcp

Figure 1.6 shows how t he service is specified in t he packet . I n t his case, a UDP header has a 16- bit field known as t he dest inat ion port . This is where t he desired service or port is found. I n t his exam ple, t he value in t he UDP header's port num ber field would be 53, signifying t hat t his dat agram is dest ined for t he Dom ain Nam e Service. Figu r e 1 .6 . N ot j u st a ny por t .

At one t im e in hist ory, special significance was at t ached t o port s below 1024. Those lower- num bered port s were t he so- called t rust ed port s ( chuckle) because only root could use t hem . The t erm t rust ed port originat ed because port s below 1024 were allocat ed t o syst em processes. Therefore, if a foreign host saw an incom ing connect ion wit h a source port less t han 1024, it was assum ed t o be t rust ed because it ost ensibly cam e from a syst em process. This m ade m uch m ore sense when t he I nt ernet was a safer place. This is m uch less t rue t oday, but t he port s above 1024 have special significance. These are oft en called t he ephem eral port s, which m eans t hey could be used by m ost any service for m ost any reason.

I P Pr ot ocols Turn your at t ent ion again t o t he four prim ary layers of t he TCP/ I P m odel ( refer back t o Figure 1.1) . You ( as t he user) use an applicat ion t o int eract wit h t he I P com m unicat ions st ack. You use a program such as FTP t o t ransfer files, t elnet as a t erm inal em ulat or, and em ail t o forward t ired j okes and st ories t o 50 of your closest friends. The applicat ion t akes t he m essage, t he inform at ion from t he user or user process, and prepares it t o be sent down t hrough t he I P st ack. The rem aining t hree layers are t ransport , net work, and link. Two different t ransport m odels are discussed at t his point : a connect ion- orient ed m odel ( TCP) and a connect ionless m odel ( UDP) . Connect ion- orient ed m eans j ust what it sounds like: The soft ware does everyt hing t hat it can t o ensure t hat t he com m unicat ion is reliable and com plet e and begins t he process by est ablishing a connect ion known as a handshake. Connect ionless, on t he ot her hand, is a sendand- pray delivery t hat has no handshake and no prom ise of reliabilit y. Any offered reliabilit y m ust be built in t o t he applicat ion. Table 1.3 shows som e of t he TCP and UDP at t ribut es.

Ta ble 1 .3 . At t r ibu t e s of TCP Ve r su s UD P

TCP Reliable

UD P Unreliable

Connect ion- orient ed

Connect ionless

Slower

Fast er

UDP is t he easiest com m unicat ion prot ocol t o com prehend—aft er all, you j ust assem ble packet s and fire t hem int o t he net work. The dest inat ion host scoops t hem up, dem ult iplexes ( st rips t he headers off at one layer and sends it t o t he appropriat e upper- layer prot ocol) , and ext ract s t he m essage. Cert ainly, a few dat agram s m ight get lost along t he way, but t hat is oft en okay; for plent y of applicat ions, t his is not an issue. I f you were broadcast ing audio, for inst ance, and a word got lost , your m ind could probably com pensat e for t his and fill in t he m issing word. I f you were sending video, perhaps t here would be a lit t le blank spot where som e packet s got lost . Most of t he t im e, t his is accept able. The dat a t hat t ravels over UDP is not necessarily unreliable; it is j ust t hat UDP it self is not responsible for it . The applicat ion m ust ignore t he m issing pieces or ask for t he m issing pieces. What if you have an applicat ion t hat cannot t olerat e t he loss of packet s? That is when TCP is used. I t ensures t hat all dat a sent is received. Several m echanism s are in place t o verify delivery and proper sequencing of TCP dat a. One m eans of cont rol is an acknowledgem ent . An acknowledgem ent ( ACK) is an im port ant part of t he TCP prot ocol. TCP is so reliable because each packet is acknowledged aft er t he dest inat ion host receives it . I f a packet is not received ( and t herefore not acknowledged) , it is resent . Thus, TCP ensures t hat all t he packet s are received, and so is deem ed a reliable service. This is a m uch slower way of doing business, but you can set cert ain opt im izat ions t o speed up t he process. That said, TCP will always be slower t han UDP. The final I P prot ocol discussed here is t he I nt ernet Cont rol Message Prot ocol ( I CMP) , which is a fascinat ing light weight set of applicat ions originally creat ed for net work t roubleshoot ing and t o report error condit ions. The m ost well- known I CMP applicat ion is cert ainly t he echo request / echo reply ( or ping) . You can use a ping t o det erm ine whet her a given net work host is reachable. Ot her I CMP applicat ions are used for such t hings as flow cont rol, packet rerout ing, and net work inform at ion collect ion ( t o nam e j ust a few of t he funct ions) . Chapt er 4, " I CMP," discusses I CMP and it s relat ed funct ions in m ore det ail.

D om a in N a m e Syst e m Nam ing a t hing is not t he sam e as knowing a t hing, but it is oft en t he first st ep. I rem em ber when I first st art ed hearing about t he Dom ain Nam e Syst em ( DNS) . At t he t im e, t he m aj or dat abase soft ware vendors were all t alking about t heir dist ribut ed dat abase product s t hat would be available " real soon now," and t hen t he next t hing I knew I was running dist ribut ed dat abase soft ware. I t didn't cost m e a t hing, and it worked from day one. DNS is a dist ribut ed dat abase because

t he ent ire address t able is not st ored on a single host ; inst ead, it is dist ribut ed across m any servers. At one point , t he I P addresses and nam es were kept in t ables t hat were downloaded night ly. As t he I nt ernet kept growing, t his becam e im pract ical for a num ber of reasons relat ed t o t he size of t he t able and issues surrounding single point of failure. Take a look at t his excerpt of t he st at ic host file / et c/ host s m aint ained on a UNI X host :

/etc/hosts 127.0.0.1 172.20.1.41 172.20.31.19

loopback relay relay.sans.org goo goo.sans.org

Alt hough UNI X and Windows 2000 host s st ill m aint ain a sm all local host s file t o ident ify local and frequent ly used host s, t his funct ion has been augm ent ed by adding DNS capabilit ies. Most UNI X and Windows 2000 host s are configured t o search t he host 's file first and if a host is not found t here, t o search DNS for t he resolut ion for t he host . This offloads m ost of t he m aint enance burden from t he syst em adm inist rat or t o individual adm inist rat ors who m aint ain DNS servers. Before j um ping int o t he DNS, a discussion of DNS dom ains is needed. A dom ain is really j ust a logical division of DNS or t he DNS dat abase. The init ial seven wellknown " generic" dom ains have t he t hree- let t er endings such .com , .org, .edu, .net , and t o a lesser ext ent .int , .gov, and .m il. The list of t op- level dom ains has been expanded t o include .aero, .biz, .coop, .info, .m useum , .nam e, and .pro. There are also t wo- let t er dom ains, which oft en appear as count ry codes ( .us, .fr, and .uk for t he Unit ed St at es, France, and t he Unit ed Kingdom ) . Wit hin each of t hose generic dom ains are t he dom ains used every day ( for exam ple, yahoo.com and sans.org) . Each of t hese dom ains represent s a slice of t he ent ire DNS pie. Now t hat you have been int roduced t o t he concept of DNS dom ains, how does DNS nam e resolut ion really work? At a very rudim ent ary level, t here are basically t wo resolving rout ines: get host byaddr and get host bynam e. When you do som e kind of DNS resolut ion, a host needs t o eit her t ranslat e an I P num ber int o a host nam e or a host nam e int o an I P num ber. The real issue at hand is t hat people refer t o host s by t heir God- given host nam es, whereas com put ers refer t o host s by t heir binary- derived I P num bers. Aft er all, t here is no field in an I P dat agram for t he host nam e, only t he I P num ber. The get host byaddr call issued by your host delivers an I P num ber t o a DNS server and t ells it t o resolve t he host nam e and ret urn it . There is m uch m ore t o t he process t han m eet s t he superficial eye, and t his is discussed in Chapt er 6, " DNS." Conversely, a get host bynam e call delivers a host nam e t o a DNS server and request s resolut ion t o an I P num ber. Underst and t hat t his explanat ion of DNS is a gross oversim plificat ion of t he processes and issues involved because it is int ended

t o be a very int roduct ory exposure.

Rou t in g: H ow You Ge t Th e r e fr om H e r e Do you rem em ber reading about TCP/ I P as a four- layer prot ocol st ack: applicat ion, t ransport , net work, and link? Som e t im e was t aken t o explain what t he applicat ion and t ransport layers do, but t he explanat ion st opped at t he net work layer. Well, t he net work layer is concerned wit h rout ing and how t o get from one host t o anot her host regardless of t he physical int erconnect ion or t he layout of t he net work. A bet t er nam e for t his layer m ight be t he I P layer because t his is t he layer at which I P addresses are used and rout ing occurs. I t is significant t o underst and t hat I P doesn't concern it self wit h t he underlying physical link. You have already learned about t he m echanism used t o direct t raffic t o a host t hat resides on a net work wit h t he sam e net work I D and subnet m ask as t he sending host . ARP is used t o broadcast a request t o all host s on t he local net work asking one t o respond wit h a MAC address t hat m at ches t he desired dest inat ion I P num ber. How t hen is t raffic direct ed t o ot her net works since ARP is broadcast only on t he local net work? That is where rout ing com es in. Each host has a rout ing t able t hat knows about a default rout er. When t he dest inat ion host is not on t he local net work, t he t raffic t o be sent is direct ed t o t he default rout er. The rout er is responsible for forwarding t he t raffic one hop closer t o it s dest inat ion. This hop can be t o anot her rout er or t o t he dest inat ion host it self if it resides on a net work direct ly connect ed t o t he rout er's int erface. The quest ion t hen becom es, how do rout ers know how t o correct ly direct t he t raffic and how do t hey receive updat ed inform at ion? Aft er all, t his has t o be a dynam ic process given t hat rout es change because of problem s and growt h. Rout ers m aint ain t ables of rout es t hat t hey know about . They use dynam ic rout ing prot ocols t o updat e t heir t ables. Rout ing prot ocols are divided int o t wo m aj or cat egories: I nt erior Gat eway Prot ocols ( I GPs) and Ext erior Gat eway Prot ocols ( EGPs) . The I nt erior Gat eway Prot ocols support rout ing t raffic wit hin a net work t hat is under t he sam e adm inist rat ive cont rol, also known as an Aut onom ous Syst em ( AS) . This is a fancy nam e for all t he rout ers for which a sit e has responsibilit y. The Rout ing I nform at ion Prot ocol ( RI P) is a widely deployed I GP. RI P is a sim ple prot ocol, which requires very lit t le configurat ion and is support ed by essent ially every device. Anot her I GP is Open Short est Pat h First ( OSPF) . These t wo prot ocols differ in t he way t hat t hey receive rout ing updat es and t heir perspect ive on finding best rout es. Ext erior Gat eway Prot ocols are required when packet s m ust t ravel bet ween

different Aut onom ous Syst em s. These prot ocols bridge separat e Aut onom ous Syst em s int o a single net work in which all of t he com put ers on t he net work can int eract seam lessly wit h each ot her. The Border Gat eway Prot ocol ( BGP) is a widely used Ext erior Gat eway Prot ocol. Current ly, BGP provides t he rout ing prot ocol t hat support s t he I nt ernet backbone. BGP servers on t he I nt ernet backbone m ust m aint ain rout ing t ables t hat include all of t he ext ernal addresses on t he I nt ernet —a pret t y daunt ing t ask.

Su m m a r y A lot of new and diverse t opics have been j am - packed int o t his int roduct ory chapt er. Det ails aside, you need t o t ake away som e core concept s wit h you t o underst and t he upcom ing chapt ers on TCP/ I P. First , visualize t he t ransfer of dat a bet ween t wo net worked host s as a series of layers, m uch like a st ack. On t he sending end, t he m essage t o be delivered is encapsulat ed in a series of headers as it is passed down t he st ack. On t he receiving end, t he process is reversed and t he encapsulat ing headers are st ripped and delivered t o t he associat ed layer of t he st ack for processing. Each layer on t he sending host really com m unicat es wit h it s peer layer on t he receiving host . Dat a is exchanged and packaged in different bundles wit h different nam es depending on t he purpose of t he dat a and t he layer at which it is found in t he TCP/ I P st ack. Host s are addressed as bot h I P num bers and MAC num bers at different layers of t he TCP/ I P st ack. Rem em ber t hat port num bers are used wit h TCP and UDP t o designat e a specific applicat ion, such as sendm ail or t elnet . TCP is t he connect ionorient ed prot ocol t hat prom ises delivery, whereas UDP m akes no such prom ise and is considered unreliable. DNS is used t o t ranslat e host nam es t o I P addresses and vice versa. Finally, rout ing is responsible for t ransport ing t he dat agram from source t o dest inat ion host . TCP/ I P is a vast and com plex t opic.Various aspect s of it will be exam ined in m ore det ail in subsequent chapt ers of t his part of t he book.

Ch a pt e r 2 . I n t r odu ct ion t o TCPdu m p a n d TCP

Now t hat you have learned a bit about I nt ernet Prot ocol ( I P) , you can t ake a closer look at how it works by using a pract ical analysis t ool known as TCPdum p. Just as you cannot do any kind of int rusion det ect ion or t raffic analysis wit hout knowledge of TCP/ I P, you cannot do analysis wit hout a t ool of som e sort . TCPdum p, or it s Windows cousin Windum p, is a popular and widely used piece of soft ware t hat can give you som e insight int o t he t raffic act ivit y t hat occurs on a given net work. This chapt er t eaches you how t o m anipulat e t he t ool for your own purposes and explains t he out put t hat it displays. The discussion t hen t urns t o one of t he m ost im port ant and com m on prot ocols, TCP. You are int roduced t o som e t heory, but t he real goal is t o enable you t o cat ch a visual clue about TCP's behavior by exam ining it using TCPdum p. An excellent free t ool for packet sniffing and int erpret at ion is known as Et hereal, which is available for bot h Windows and UNI X. I t provides a GUI int erface t o int erpret all layers of t he packet and m any t im es t he payload. I t is even prot ocol aware, m eaning t hat it knows how t o int erpret t he payload of m any com m on prot ocols. For inst ance, it would know how t o decipher a norm ally coded DNS query. You are probably wondering why Et hereal is not being used as t he t ool of choice in t his book. First , it is m ore difficult t o t ranslat e t he Et hereal out put t o readable book form at . TCPdum p is m ore succinct and m ore easily viewed. Second, TCPdum p is m ore prim it ive because it requires t he user t o do m uch of t he int erpret at ion of t he out put . The challenge is t o m ake you t hink rat her t han hand you all t he answers, as Et hereal does. The second part of t his chapt er begins t he discussion of net work prot ocols wit h a discussion of TCP. All t he chapt ers in t his book t hat discuss net work prot ocols follow a sim ilar form at . To give you insight int o " norm al" act ivit y, t he prot ocol is first present ed as you would expect t o see it under norm al circum st ances. However, because t he I nt ernet has becom e a wild and unpredict able arena, you are quit e likely t o see aberrant kinds of act ivit y t oo. Each prot ocol chapt er

discusses som e of t he deviant depart ures you m ight encount er. This chapt er follows t hat basic form at .

TCPdu m p TCPdum p is a UNI X t ool used t o gat her dat a from t he net work, decipher t he bit s, and display t he out put in a sem i coherent fashion. The sem i coherent out put becom es fully coherent out put wit h a lit t le explanat ion and exposure t o t he t ool. When I first cam e t o work at t he Dahlgren Navy Laborat ory, for exam ple, I spent t he first week wat ching a net work analyzer. My boss, Bob Hot t , cam e by every couple of hours t o ask quest ions or have m e give him a sm all assignm ent . At t he end of t he week, he had learned som et hing about t he behavior of I P and t he charact er of his net work. I st rongly encourage you t o spend som e t im e wat ching your net work t raffic; your invest m ent will pay off for you m any t im es over in your j ourney as an analyst . Alt hough out put from com m ercial t ools m ight differ slight ly or be m ore fashionable t han TCPdum p, TCPdum p runs close t o t he m et al and can help you underst and ot her t ools as well. This sect ion dem onst rat es t he use and dem yst ifies t he out put of TCPdum p.

W h e r e D o You Ge t TCPdu m p a n d I t s Va r ia n t s? You can download TCPdum p from ft p: / / ft p.ee.lbl.gov/ t cpdum p.t ar.Z You need t o download soft ware known as libpcap, which im plem ent s a port able fram ework for capt uring low- level net work t raffic. You can find it at ft p: / / ft p.ee.lbl.gov/ libpcap.t ar.Z This is t he " official" version of TCPdum p; Lawrence Berkeley Labs aut hored it . Yet , m ore recent ly, a collect ive effort has arisen t o m aint ain and im prove t he code. More feat ure- rich versions are being developed and can be found at ht t p: / / www.t cpdum p.org/ Windum p is a Windows variant of TCPdum p. You can download it from ht t p: / / net groupserv.polit o.it / windum p I t also requires winpcap soft ware t o funct ion. You can obt ain winpcap from t his sam e sit e. TCPdu m p Be h a vior Aft er TCPdum p has been inst alled, m ost operat ing syst em s require root access t o run it . This is because reading packet s requires access t o devices accessible t o

root - only. TCPdum p is run by issuing t he com m and t cpdum p. By default , t his reads all t he t raffic from t he default net work int erface and spews all t he out put t o t he console. This is not always t he behavior t he user want s; in fact , t his is pret t y irrit at ing because records are likely t o fly by uncont rollably on a busy net work. Therefore, m any different com m and- line opt ions are available t o alt er t he default behavior. Filt e r s

Suppose, for inst ance, t hat you don't want t o collect all t he t raffic from t he default net work int erface. Maybe you are int erest ed only in TCP records. TCPdum p has a filt er t hat enables you t o specify t he records t hat you are int erest ed in collect ing. TCPdum p com es com plet e wit h a filt er " language" t o denot e t he field( s) in an I P dat agram t hat should be exam ined and ret ained if t he specified condit ions are m et . To collect only TCP records, issue t he com m and t cpdum p 't cp'. The filt er in t his exam ple is 't cp'. Filt ers get m uch m ore com plicat ed and rest rict ive t han t his sim ple one when you use com binat ions of fields and t rait s. Just about any field in an I P dat agram , including t he act ual dat a payload, can be used t o lim it t he purview of collect ed records. I t seem s logical t hat TCPdum p should include a way t o indicat e t hat t he filt er is st ored in a file so t hat users don't have t o t ype a long filt er com plet e wit h ham - handed keyst rokes on t he com m and line it self. And t rue t o logic, TCPdum p has an –F filenam e opt ion t o indicat e t hat t he filt er is locat ed in t he file filenam e. Bin a r y Colle ct ion

As m ent ioned earlier, TCPdum p dum ps all t he collect ed out put t o t he screen. This is t olerable behavior if you are looking for a specific record. Most t im es, however, TCPdum p is running in unat t ended m ode, gat hering records for ret rospect ive analysis. To gat her dat a for ret rospect ive analysis, you want TCPdum p t o collect t he records in a binary form at , also known as raw out put . When TCPdum p displays records on t he console, t hey have been t ranslat ed from t he nat ive raw out put form at t o a hum an- readable form at . For ret rospect ive analysis, t he desired form at for st orage is t he binary m ode, in which all capt ured dat a is st ored, not j ust t he dat a t ranslat ed for out put . To collect in raw out put m ode, use t he com m and t cpdum p –w filenam e, in which filenam e is t he nam e of t he file t o which t he records will be writ t en in binary form at . To read t his raw out put file, anot her com m and- line opt ion is necessary: t cpdum p – r filenam e. This opt ion reads input t o TCPdum p from filenam e rat her t han from t he default net work int erface. You can read a file t hat has been writ t en using t he –w opt ion only by using TCPdum p wit h t he –r opt ion. I f you have ever used t he UNI X t ar ut ilit y, you know t hat when you creat e a t ar file, oft en referred t o as a t arball, you m ust read t hat sam e t ar file using t ar. The sam e principle applies wit h TCPdum p.

Alt e r in g t h e Am ou n t of D a t a Colle ct e d

One final opt ion is discussed before proceeding because it det erm ines t he am ount of dat a t hat TCPdum p collect s. TCPdum p does not at t em pt t o collect t he ent ire dat agram sent . The reason for t his is due t o volum e concerns and m any t im es t he user's int erest is in t he header port ions of t he dat agram t hat are usually collect ed wit h t he default lengt h. The snapshot lengt h, som et im es known as snaplen, det erm ines t he exact num ber of byt es collect ed. One of t he m ost com m on lengt hs of collect ed dat a is 68 byt es. What exact ly do you get wit h t hese 68 byt es of dat a? Figure 2.1 shows a sam ple breakdown of a packet . The header fields can be different lengt hs t han depict ed, based on t he prot ocol and header opt ions. First you have an encapsulat ing link layer header—if t his were Et hernet , it would represent 14 byt es of Et hernet fram e header wit h fields such as source and dest inat ion MAC addresses. Next , you have an I P dat agram header, which is m inim ally 20 byt es if t here are no I P opt ions. The encapsulat ed prot ocol header ( TCP, UDP, I CMP, and so on) follows t hat and can range from 8 byt es t o m ore t han 20 byt es for TCP headers wit h opt ions. The dat a, or payload in t he dat agram , is collect ed aft er all t he headers. As you can see, t here m ight not be m uch, if any, payload collect ed because of t he default snaplen. To alt er t he default snaplen, use t he t cpdum p –s lengt h com m and, in which lengt h is t he desired num ber of byt es t o be collect ed. I f you want t o capt ure an ent ire Et hernet fram e ( not including 4 byt es of t railer) , use t cpdum p –s 1514. This capt ures t he 14- byt e Et hernet fram e header and t he m axim um t ransm ission unit lengt h for Et hernet of 1500 byt es. Figu r e 2 .1 . Sa m ple pa ck e t .

You can use m any m ore com m and- line opt ions wit h TCPdum p. To learn about t hem , issue t he com m and m an t cpdum p com m and. Be warned, however, t hat t he out put is copious ( change t he print er cart ridge and rest ock t he paper) , but very inform at ive if you have t he pat ience and curiosit y t o wade t hrough it . TCPdu m p Ou t pu t Because you will be seeing m any TCPdum p t races in t his book, it is im port ant for you t o underst and t he form at . One of t he hardest t asks for t he novice analyst t o m ast er is decrypt ing TCPdum p out put . TCPdum p out put is fairly st andard for t he

different prot ocols ( TCP, UDP, I CMP, for exam ple) , but does have som e nuances. The first st ep is t o ident ify t he prot ocol t hat you are exam ining. TCP out put will be used t o explain t he general TCPdum p form at . Here is a TCP record displayed by TCPdum p:

09:32:43:910000 nmap.edu.1173 > dns.net.21: S 62697789:62697789(0) win 512 z

09:32:43:9147882

z

nmap.edu

z

1173

z

>

z

dns.net

z

This is t he t im e st am p in t he form at of t wo digit s for hours, t wo digit s for m inut es, t wo digit s for seconds, and six digit s for fract ional part s of a second. This is t he source host nam e. I f t here is no resolut ion for t he I P num ber or t he default behavior of host nam e resolut ion is not request ed ( TCPdum p - n opt ion) , t he I P num ber appears and not t he host nam e. This is t he source port num ber, or port service.

This is t he m arker t o indicat e a direct ional flow going from source t o dest inat ion. This is t he dest inat ion host nam e.

This is t he dest inat ion port num ber ( for exam ple, 21 m ight be t ranslat ed as FTP) . 21

z

S

z

62697789:62697789(0)

z

win 512

This is t he TCP flag. The S represent s t he SYN flag, which indicat es a request t o st art a TCP connect ion. This is t he beginning TCP sequence num ber: ending TCP sequence num ber ( dat a byt es) . Sequence num bers are used by TCP t o order t he dat a received. For a session est ablishm ent such as t his, t he beginning sequence num ber represent s t he init ial sequence num ber ( I SN) , select ed as a unique num ber t o m ark t he first byt e of dat a. The ending sequence num ber is t he beginning sequence num ber plus t he num ber of dat a byt es sent wit hin t his TCP segm ent . As you see, t he num ber of dat a byt es sent for a session est ablishm ent request is usually 0. That is why t he beginning and ending sequence num bers are t he sam e. Norm al session est ablishm ent s do not send dat a. This is t he receiving buffer size ( in byt es) of nm ap.edu for t his connect ion.

TCP Fla gs

Norm al TCP connect ions have one or m ore flags set . Flags are used t o indicat e t he funct ion of t he connect ion. Table 2.1 shows t he TCP flags, t heir represent at ion in TCPdum p, and t heir m eanings.

Ta ble 2 .1 . TCPdu m p Fla gs

TCP Fla g

Fla g Re pr e se n t a t ion

Fla g M e a n in g

SYN

S

This is a session est ablishm ent request , which is t he first part of any TCP connect ion.

ACK

ack

This flag is used generally t o acknowledge t he receipt of dat a from t he sender. This m ight be seen in conj unct ion wit h or " piggybacked" wit h ot her flags.

FI N

F

This flag indicat es t he sender's int ent ion t o gracefully t erm inat e t he sending host 's connect ion t o t he receiving host .

RESET

R

This flag indicat es t he sender's int ent ion t o im m ediat ely abort t he exist ing connect ion wit h t he receiving host .

PUSH

P

This flag im m ediat ely " pushes" dat a from t he sending host t o t he receiving host 's applicat ion soft ware. There is no wait ing for t he buffer t o fill up. I n t his case, responsiveness, not bandwidt h efficiency, is t he focus. For m any int eract ive applicat ions such as t elnet , t he prim ary concern is t he quickest response t im e, which t he PUSH flag at t em pt s t o signal.

URGENT

urg

This flag indicat es t hat t here is " urgent " dat a t hat should t ake precedence over ot her dat a. An exam ple of t his is pressing Ct rl+ C t o abort an FTP download.

Placeholder .

I f t he connect ion does not have a SYN, FI N, RESET, or PUSH flag set , a placeholder ( a period) will be found aft er t he dest inat ion port .

TCPdum p out put for TCP is unique; t he flag field and t he sequence num bers are dist inguishing charact erist ics. When you see t hese t ellt ale signs in t he TCPdum p out put , you know t he record is TCP. UDP records are likely t o have t he word udp in t he TCPdum p out put . Alt hough t rue m ost of t he t im e, j ust when you t hink you can rely on t his as a st eadfast way t o ident ify UDP out put , TCPdum p t hrows you a

curve ball. TCPdum p analyzes som e UDP services, such as Dom ain Nam e Service ( DNS) and Sim ple Net work Managem ent Prot ocol ( SNMP) , at t he applicat ion level in addit ion t o t he prot ocol level as UDP. Like Et hereal, it is prot ocol aware and can int erpret norm ally coded payloads of cert ain prot ocols. The out put m ight look foreign t o you t he first few t im es you see it because it does not have t he word udp and because t here are no TCP t radem arks such as flags or sequence num bers. Typically, t his is UDP out put wit h m ore det ail. Finally, I CMP is easily ident ified because t he word icm p appears, wit hout except ion, in t he TCPdum p out put . Absolu t e a n d Re la t ive Se qu e n ce N u m be r s Not t o belabor t he discussion of TCPdum p out put any m ore t han is necessary, but TCP sequence num bers need t o be addressed in a lit t le m ore det ail. Sequence num bers are associat ed only wit h TCP out put , as j ust discussed. TCP sequence num bers are used by t he dest inat ion host t o reassem ble TCP t raffic t hat arrives. Rem em ber t hat TCP guarant ees order, whereas UDP does not . The sequence num bers are decim al num ber represent at ions of a 32- bit field, so t hey can be pret t y m onst rous in size and int im idat ing t o read. TCPdum p helps m ake t he out put m ore coherent by changing from t he absolut e I SNs t o relat ive sequence num bers aft er t he t wo host s exchange t heir I SNs. Look at t he following TCPdum p out put . The t im e st am p has been om it t ed for t he clarit y and space- saving considerat ions:

client.com.38060 > telnet.com.telnet: (DF) telnet.com.telnet > client.com.38060: 3774957991 win 1024 client.com.38060 > telnet.com.telnet: client.com.38060 > telnet.com.telnet:

S 3774957990:3774957990(0) win 8760 S 2009600000:2009600000(0) ack .ack 1 win 8760 (DF) P 1:28(27) ack 1 win 8760 (DF)

The sect ion, " Est ablishing a TCP Connect ion," discusses t he act ual t heory of t his out put . For now, however, look at t he num bers in bold. The first t wo num bers in t he first t wo lines in bold represent t he very large I SNs in absolut e form at t hat are exchanged from client .com and t elnet .com , respect ively. The t hird line has a num ber in bold t hat represent s a relat ive sequence num ber—1. This m eans t hat client .com has acknowledged receiving t he previous SYN by t elnet .com wit h an I SN of 2009600000. The 1 as t he acknowledgem ent value m eans t hat t he next expect ed relat ive byt e t o be received by client .com is byt e 1. That would have an absolut e sequence num ber of 2009600001, if it were not displayed as a relat ive sequence num ber. I f t his seem s confusing, t he t heory of acknowledgem ent num bers will be discussed in m ore det ail in t he upcom ing sect ion " I nt roduct ion t o TCP." The final line has t he num bers 1 and 28 in bold t o indicat e t hat relat ive t o t he absolut e sequence num ber of 3774957990, t he 1st byt e t hrough ( but not including) t he 28t h byt e are sent from client .com t o t elnet .com . The final line also has ack 1.. This acknowledgem ent num ber will not change unt il t elnet .com sends

m ore dat a. I f you ever need t o leave t he sequence num bers in t heir absolut e form , t he TCPdum p –S opt ion will alt er t he default behavior of expressing TCP sequence num bers in relat ive t erm s aft er t he exchange of t he I SNs.

Ch a n gin g t h e TCPdu m p Colle ct ion I n t e r fa ce You m ight find t hat you want t o read TCPdum p t raffic from a different int erface t han t he default one. The default int erface is t he lowest num ber act ive one, not including t he loopback int erface. For inst ance, if you were on a Linux box and had t wo NI C cards, one m ight be known as et h0 and t he next et h1. To change t he default int erface, t he –i opt ion of TCPdum p is used. The following com m and will select ppp0 as t he list ening int erface:

tcpdump –i ppp0

D u m pin g in H e x a de cim a l TCPdum p does not display all t he fields of t he capt ured dat a. For exam ple, t he I P header has a field t hat st ores t he lengt h of t he I P header. How do you display t his field if it is not available from t he st andard TCPdum p out put ? There is a TCPdum p com m and- line opt ion ( –x) t hat dum ps t he ent ire dat agram capt ured wit h t he default snaplen in hexadecim al. Hexadecim al out put is far m ore difficult t o read and int erpret , but it is necessary t o display t he ent ire capt ured dat agram . To int erpret TPCdum p hexadecim al out put , you need som e reference m at erial t hat discusses t he form at of t he I P dat agram headers and describes what each of t he fields represent s. ( One such reference t it le is TCP/ I P I llust rat ed, Volum e 1, by W. Richard St evens.) You t hen m ust t ranslat e hexadecim al t o decim al for num eric fields and num eric t o ASCI I for charact er fields. Et hereal is probably t he best t ool t o use for t ranslat ion of TCPdum p records t hat are st ored in binary form wit h t he – w t cpdum p com m and line opt ion; it can read TCPdum p binary dat a as input .

I n t r odu ct ion t o TCP TCP is a reliable connect ion- orient ed prot ocol used wit h well- known applicat ions such as t elnet or sm t p. An applicat ion such as t elnet cannot t olerat e t he uncert aint y of t he I nt ernet Prot ocol t hat can lose dat agram s or deliver t hem in a

different order from which t hey were sent . TCP is t he prot ocol t hat orchest rat es and ensures reliabilit y. I t does so using t he following m echanism s: z

z

z

Exclusive TCP connect ion. When a TCP session is est ablished, t he connect ion is exclusive and unique bet ween t he t wo host s. This kind of connect ion is called a unicast connect ion. The negot iat ion of t he unique session allows bot h sides t o t rack t he t raffic exchanged bet ween t he t wo host s. TCP sequence num bers. These provide a sense of chronology t o t he TCP dat a sent and received. A t elnet com m and or exchange m ight t ake several packet s known as TCP segm ent s t o t ransm it all t he dat a. Dat a is assigned a TCP sequence num ber t o uniquely ident ify t he dat a in each segm ent being sent . Because t he dat a m ight arrive in a different order from which it was sent , TCP sequence num bers are also used t o reassem ble t he dat a in t he correct order. Acknowledgem ent s. Acknowledgem ent s are used t o inform t he sender t hat dat a has been received. Acknowledgem ent s are m ade t o sequence num bers t o ident ify t he exact dat a received. I f t he sender does not receive an acknowledgem ent for specific dat a in a given t im e, it assum es t hat t he dat a has been lost . The sender will ret ransm it what it believes was lost .

Est a blish in g a TCP Con n e ct ion Figure 2.2 shows est ablishing a TCP connect ion is alm ost cerem onial in nat ure, involving what is com m only known as t he t hree- way handshake. This is norm ally com plet ed before any dat a is passed bet ween t wo host s. What is depict ed is t he client or source host init iat ing a connect ion t o t he server or dest inat ion host . The t erm client is used t o m ean t he host request ing som e kind of service from anot her host . A server is a host t hat list ens on a well- known port num ber for request s of a part icular service. TCP requires a dest inat ion port or service t o be specified. Exam ples of dest inat ion port s are 23 ( t elnet ) , 25 ( sm t p) , or port 80 ( also known as t he HTTP or t he web server port ) . Figu r e 2 .2 . Th e t h r e e - w a y h a n dsh a k e .

The t hree- way handshake proceeds as follows: 1 . The client sends a SYN ( SYNC) t o signal a request for a TCP connect ion t o t he server. 2 . I f t he server is up and offers t he desired service, and can accept t he incom ing connect ion, it sends a connect ion request of it s ow n signaled by a new SYN ( SYNS) t o t he client and acknowledges t he client 's connect ion request wit h an ACK ( ACKC) . This is all accom plished in a single packet . 3 . Finally, if t he client receives t he server's SYN and ACK of t he SYN t hat t he client sent and st ill want s t o cont inue t he connect ion, it sends a final lone ACK ( ACKS) t o t he server. This acknowledges t hat t he client received t he server's request for a connect ion. Aft er t he t hree- way handshake has been execut ed in t his m anner, t he connect ion has been est ablished. Dat a can now be exchanged bet ween t he t wo host s. I f you exam ine t he t hree- way handshake wit h a lit t le m ore scrut iny, you will discover t hat t wo connect ions have really been est ablished. The first is bet ween t he client and server and t he second bet ween t he server and t he client . This is because TCP is full duplex , which m eans t hat dat a exchanges can t ravel in eit her direct ion independent ly. The following exam ple shows t he t hree- way handshake, using TCPdum p t o display t he exchange:

tclient.net.39904 > telnet.com.23: S 733381829:733381829(0) win 8760 (DF) telnet.com.23 > tclient.net.39904: S 1192930639:1192930639(0) ack 733381830 win 1024 (DF) tclient.net.39904 > telnet.com.23: . ack 1 win 8760 (DF)

I n t he first record, you see t he client , t client .net , at t em pt a connect ion t o t he t elnet server, port 23, of t elnet .com . You see t he SYN flag set followed by t he I SN, 733381829, and t he sam e ending sequence num ber, 0 payload byt es in t he parent heses. Aft er t hat , you see a window size of 8760 and a m axim um segm ent size ( m ss) t hat it advert ises t o t he server. The window size of 8760 says t hat t he client has an 8760- byt e buffer for aggregat ed incom ing dat a t o t his connect ion. The m ss inform s t he dest inat ion host t hat t he physical net work on which t client .net resides should not receive m ore t han 1460 byt es of TCP payload ( 20byt e I P header + 20- byt e TCP header + 1460- byt e payload = 1500 byt es, which is t he m axim um t ransm ission unit , or MTU, for Et hernet ) at a t im e. I n t his case, even t hough t he client , ( t client .net ) can accept 8760 byt es of dat a, t he physical m edium on which it resides, m ost likely Et hernet , cannot accept m ore t han 1460 byt es for a TCP payload size.

I n t he second record, you see t elnet .com send a SYN and an ACK t o t client .net inform ing it t hat it is an available and willing part icipant in t his connect ion and is willing t o est ablish one of it s own as well. t elnet .com inform s t client .net of it s I SN, 1192930639. This is also t he ending sequence num ber because no dat a is sent ; t his is norm al for t he SYN/ ACK records. The num ber following t he ACK is t he acknowledgem ent num ber, in t his case, 733381830. Not e t hat t his value is t he I SN advert ised by t client .net in t he first record 733381829 plus 1. t elnet .com has j ust acknowledged t hat it expect s absolut e byt e num ber 733381830 as t he next sequence num ber from t client .net . t elnet .com advert ises a window size of 1024 and a m axim um segm ent size of 1460. I n t he final line, t client .net sends t he final lone ACK t o t elnet .com and acknowledges receiving t he SYN/ ACK flags from t elnet .com . The value of 1 as t he relat ive acknowledgem ent num ber indicat es t hat it next expect s t he first byt e from t elnet .com . Also, not ice t hat t he sequence num bers have changed from absolut e t o relat ive values beginning wit h t his record. Right aft er t he dest inat ion part , following t he colon, you see a period. Rem em ber t his is t he placeholder value when none of t he PUSH, RESET, SYN, or FI N bit s is set . Se r ve r a n d Clie n t Por t s I n t he past , m ore so t han t oday, well- known server port s generally fell in t he range of 1–1023. Hist orically under UNI X, only processes running wit h root privilege could open a port below 1024. These port s should rem ain const ant on t he host for which t hey are offered. I n ot her words, if you find t elnet at port 23 on a part icular host one day, you should find it t here t he next day. You will find m any of t he older well- est ablished services in t his range of 1–1023 ( such as t elnet on port 23 and sm t p on port 25) . Today, som e of t he newer services, such as AOL I nst ant Messenger, usually associat ed wit h TCP port 5190, don't t end t o conform t o t his original convent ion. This is part ially because t here are m ore services t han num bers in t his range t oday. Client port s, oft en known as ephem eral port s, are select ed only for a part icular connect ion and are reused aft er t he connect ion is freed. These are generally num bered great er t han 1023. When a client init iat es a connect ion t o a server, an unused ephem eral port is select ed. For m ost services, t he client and server cont inue t o exchange dat a on t hese t wo port s for t he ent iret y of t he session. This connect ion is known as a socket pair and it will be unique. There will be only one connect ion on t he I nt ernet t hat has t his com binat ion of source I P and source port connect ed t o t his dest inat ion I P and dest inat ion port . Som eone from t he sam e source I P m ight even be connect ed t o t he sam e dest inat ion I P and port . This user will be given a different ephem eral port , however, t hus dist inguishing it from t he ot her connect ion t o t he sam e server and dest inat ion port . Two users on t he sam e host m ight connect t o t he sam e web server. Alt hough t his is t he sam e source I P, dest inat ion I P, and port ( 80) , t he web server can m aint ain who get s what by t he ephem eral source port s involved.

Exam ine t he t hree- way handshake exchange again, but t his t im e in t he cont ext of client and server port s:

tclient.net.39904 > telnet.com.23: S 733381829:733381829(0) win 8760 (DF) telnet.com.23 > tclient.net.39904: S 1192930639:1192930639(0) ack 733381830 win 1024 (DF) tclient.net.39904 > telnet.com.23: . ack 1 win 8760 (DF)

You see t hat t client .net has select ed ephem eral port 39904 on which t o com m unicat e and t o connect t o well- known port 23 of t elnet .com . Any furt her exchanges aft er t he t hree- way handshake are done using t hese t wo negot iat ed port s. Aft er t he connect ion is closed and som e t im e has passed, t client .net releases port 39904 for use by anot her connect ion. Port 23 of t elnet .com rem ains bound t o t he t elnet service for addit ional t elnet request s. Con n e ct ion Te r m in a t ion You can t erm inat e a session in t wo ways: t he graceful m et hod or an abrupt m et hod. The graceful m et hod is t he phone conversat ion equivalent of you saying, " Thanks, but we're not int erest ed," and hanging up on t he t elem arket er. This inform s t he t elem arket er t hat t he conversat ion is over and t hat he should now hang up and place anot her int rusive dinnert im e call t o som e ot her hapless vict im . The abrupt equivalent of t his is j ust hanging up aft er you det erm ine som eone isn't wort h your valuable t im e. Th e Gr a ce fu l M e t h od

When t he graceful TCP session t erm inat ion m et hod is conduct ed, one of t he host s, eit her t he client or server, signals wit h a FI N t o t he ot her t hat it want s t o t erm inat e t he session. The receiving host signals back wit h an ACK ( t o acknowledge t he request ) . This t erm inat es only half t he connect ion. Then, t he ot her host m ust init iat e a FI N as well, and t he receiving host needs t o acknowledge t his. Bot h sides need t o init iat e a FI N and acknowledge t he ot her's FI N because TCP is full duplex. Bot h t he client and server send dat a in an asynchronous m anner, so bot h sides of t he connect ion have t o be individually t erm inat ed. Look at t he following t wo TCPdum p exchanges: 1 . Client init iat es a close wit h a FI N, and server does an ACK, as follows:

tclient.net.39904 >telnet.com.23: F 14:14(0) ack 186 win 8760 (DF) telnet.com.23 > tclient.net.39904: . ack 15 win 1024 (DF)

2 . Server init iat es close wit h a FI N, and client does an ACK, as follows:

telnet.com.23 > tclient.net.39904: F 186:186(0) ack 15 win 1024 (DF) tclient.net.39904 > telnet.com.23: . ack 187 win 8760 (DF)

The connect ion bet ween t client .net and t elnet .com is now closed. Th e Abr u pt M e t h od The second termination method is an abrupt halting of the connection. This is done with one host sending the other a RESET. This signals the desire to abruptly terminate the connection.tclient.net.39904 > telnet.com.23: R 28:28(0) ack 1 win 8760 (DF)

This out put shows t client .com as it abort s t he connect ion t o t elnet .com . I t sends a RESET t o t elnet .net t o signal t he int ent t o t erm inat e im m ediat ely. There should be no furt her com m unicat ion bet ween t he t wo host s using t he negot iat ed session aft er t he abort . D a t a Tr a n sfe r Now t hat you know how TCP est ablishes and t erm inat es a connect ion, it is t im e t o t ake a look at what happens in bet ween. Norm ally, t he whole reason for est ablishing a session is so dat a can be exchanged bet ween t wo host s. The following dat a excerpt m ight be t ransferred bet ween t client .net and t elnet .com aft er t he t hree- way handshake and before t he t erm inat ion:

tclient.net.39904 > telnet.com.23: P 1:28(27) ack 1 win 8760 (DF) telnet.com.23 > tclient.net.39904: P 1:14(13) ack 1 win 1024 telnet.com.23 > tclient.net.39904: P 14:23(9) ack 28 win 1024

The first line shows t client .net sending 27 byt es of dat a ( a relat ive range of 1 t o 28 byt es as seen in t he parent heses) t o t elnet .com . This is t he first t im e t he new P flag has appeared; it represent s PUSH. Because t elnet is an int eract ive applicat ion t hat dem ands t he fast est response t im e available, t he PUSH flag signals t o t he receiver of t he dat a, in t his case t elnet .com , t o push t he dat a im m ediat ely t o t he t elnet applicat ion upon receipt of dat a in t he incom ing buffer. This line also acknowledges t hat t he next relat ive sequence num ber expect ed by t client .com from t elnet .com is byt e 1. The second line shows t elnet .com sending 13 byt es of dat a t o t client .com and acknowledging receipt of 1 byt e of dat a from t client .com . I t has yet t o acknowledge receipt of t he 27 new byt es j ust sent by t client .net . The final line

shows t elnet .com sending an addit ional 9 byt es t o client .com . See how t he relat ive byt es begin at 14 ( 14:23) byt es aft er t he 13 ( 1:14) preceding byt es sent from t elnet .com t o t client .net . This exchange also acknowledges receipt of 27 byt es of dat a from t client .net t o t elnet .com . You see ack 28 because t his is known as an expect at ional acknowledgem ent : Byt e 28 is t he next ant icipat ed byt e t o be received. All t raffic exchanges bet ween t he t wo host s will have t he ACK flag set aft er t he t hree- way handshake has been com plet ed. This is som et im es used as an indicat ion of an est ablished session. W h a t 's t h e Bot t om Line ? What if you need t o analyze som e t raffic for m alicious int ent ? I s it really necessary for you t o absorb all t he det ailed t heory about TCP t o do any kind of analysis of TCP t raffic of norm al or anom alous behavior? The bot t om line is t hat you can do elem ent ary analysis wit hout flipping bit s. Here are som e of t he m ore general behaviors t hat you m ight exam ine: z

z

z

Was t he t hree- way handshake com plet ed bet ween t wo host s? I f it was, t his m eans t hat t he server listens at t he port at which t he client request ed and t he server accept ed t he connect ion. This is fine if t he expect ed behavior is t hat t he server list ens at t he request ed port . However, what if t he server port is not one t hat you expect t o list en? This m ight indicat e som e service, known t o t he syst em adm inist rat or and not t o you, is running. I t m ight also m ean, however, t hat som eone m aliciously inst alled som e backdoor applicat ion on t he server wit hout your knowledge. Was dat a t ransm it t ed? I n TCPdum p out put , aft er t he TCP sequence num bers, you find t he num ber of dat a byt es in parent heses t hat were sent . I f you see dat a t ransm it t ed, t hat m eans t hat t he t wo host s are speaking t o each ot her. When you are doing som e kind of ret rospect ive analysis of unexpect ed act ivit y bet ween t wo host s, looking at t he num ber of byt es exchanged can com e in handy in assessing t he severit y of what m ight have t ranspired. You m ight not be able t o see t he act ual dat a byt es or payload, but num bers can be t elling. Lengt hy individual exchanges and t he num ber of exchanges in aggregat e can readily indicat e pot ent ial dam age by an int ruder. Who began and/ or ended t he connect ion? By det erm ining which host init iat ed and t erm inat ed t he connect ion, you get an idea of who is in cont rol. Typically, t he client request s t he connect ion and t he server responds ( as you have already seen) . Eit her host can end t he conversat ion, so observe which one init iat es t he t erm inat ion wit h a RESET or FI N.

D a m a ge Asse ssm e n t

Using TCPdum p as a det ect ive t ool t o analyze an at t em pt ed com put er break- in is like invest igat ing a burglary at t em pt or act ual burglary. The first st ep in dam age assessm ent is det erm ining whet her t he perpet rat or act ually got int o t he com put er syst em ( or in t he case of a burglary, int o t he house) . Repeat ed SYN at t em pt s t o a syst em wit hout a reply m ight be t he equivalent of j im m ying a door wit hout successful ent ry. The com plet ion of t he t hree- way handshake is t he equivalent of ent ry; it m ight j ust be t hrough t he garage door, which also requires a key t o get int o t he house, but it is indicat ive of som e kind of ent ry. The t hree- way handshake is t he evidence equivalent of finding a previous locked door now unlocked or finding st range fingerprint s inside t he locked door. The server port num ber can indicat e t he int ruder's int erest . The use of a convent ional port , such as t elnet , m eans t hat perhaps t he burglar m ight be doing a serious raid of goods ( password files, t rust ed host relat ionships, and so on) , t he equivalent of a t hief's int erest in j ewelry and appliances. What about t he unconvent ional port num bers t hat don't support a known service? I s t hat t he sign of som e kind of a j oyride t hrough your syst em j ust t o prove it can be done—kind of like com ing hom e t o find t hat som eone drank all t he m ilk in t he refrigerat or, t hrew t he em pt y cart on on t he floor, and did or t ook not hing else? Whereas t he house burglary dam age m ight be assessed by det erm ining what is blat ant ly gone ( t he big- screen TV, for exam ple) , what about a burglar who broke int o a big, fully st ocked warehouse t hat didn't keep good invent ory records? How would you m ake an assessm ent of st olen goods? Perhaps a neighbor saw a st range vehicle in t he driveway. Was it a m oving van or was it a m ot orcycle? When you exam ine t he num ber of byt es exchanged in t he TCPdum p out put , you are in effect det erm ining what kind of haul t he burglar m ade off wit h. You are m aking best - guess effort s based on t he lit t le evidence t hat you have.

TCP Gon e Aw r y I n subsequent chapt ers, you will read m any exam ples of t he m alicious at t acks t hat em ploy TCP. Appendix A, " Exploit s and Scans t o Apply Exploit s," and Appendix C, " Det ect ion of I nt elligence Gat hering," discuss scanning m et hods t hat use different and som et im es unexpect ed com binat ions of TCP flags t o perform reconnaissance on net works and circum vent det ect ion or bypass filt ering at t em pt s. The following sect ions int roduce som e ot her anom alous TCP act ivit y, such as an ACK scan, a t elnet scan, and TCP session hij acking. An ACK Sca n Scans of port s are done for a variet y of reasons, but t hey usually are used t o discover whet her a host or host s are offering a part icular service. I f a host is found

t o be offering a service t hat m ight be exploit able, t he hacker m ight t ry t o break in using som e vulnerabilit y. Oft en, scans are blat ant ; t he hacker m akes no at t em pt t o hide his reconnaissance of your net work, except t hat t he com put er from which t he scans originat e m ight be com prom ised. The hacker assum es t hat eit her no one is m onit oring t he scanning act ivit y or t hat by using t he com prom ised host , no one can ident ify t he hacker wit h t he scan. Most likely t here will be no at t ribut ion because no one can associat e t he hacker wit h t he scan. At t im es, however, t he scanner at t em pt s t o be m ore furt ive about t he reconnaissance effort s in an at t em pt t o evade not ice. Exam ine t he following act ivit y, which is TCPdum p out put of m any relat ed connect ions. The prober can ident ify live host s by t hose responding t o t he ACK scan. The delet ion of t im e st am ps m akes it m ore readable:

ack.com.23 > 192.168.2.112.23: . ack 778483003 win 1028 ack.com.23 > 192.168.31.4.23: . ack 778483003 win 1028 ack.com.143 > 192.168.2.112.143: . ack 778483003 win 1028 ack.com.143 > 192.168.31.4.143: . ack 778483003 win 1028 ack.com.110 > 192.168.2.112.110: . ack 778483003 win 1028 ack.com.110 > 192.168.31.4.110: . ack 778483003 win 1028 ack.com.23 > 192.168.14.19.23: . ack 778483003 win 1028 ack.com.143 > 192.168.14.19.143: . ack 778483003 win 1028 ack.com.110 > 192.168.14.19.110: . ack 778483003 win 1028 ack.com.23 > 192.168.33.53.23: . ack 778483003 win 1028 ack.com.23 > 192.168.37.3.23: . ack 914633252 win 1028 ack.com.23 > 192.168.14.49.23: . ack 3631132968 win 1028

The preceding scan from ack.com sends an ACK flag t o various different host s on t he int ernal 192.168 net work. A lone ACK should be found only as t he final t ransm ission of t he t hree- way handshake, an acknowledgem ent of received dat a, an acknowledgem ent of a received FI N, or dat a t hat is t ransm it t ed where t he ent ire sending buffer has not been em pt ied. This is not t he case in t his scan because no ot her t raffic is found from ack.com t o indicat e t hat t his is a react ion t o som e nat ural cat alyst . This m ight be an at t em pt t o find live host s, som ewhat akin t o t he funct ion of ping. I f a live host receives an ACK for eit her an open or closed port , it should respond wit h a RESET. Also, filt ering rout ers t hat allow only " est ablished" connect ions int o t he net work ( in ot her words, t he ACK bit is set ) will not filt er t his kind of scan. As sit es becom e m ore securit y conscious and begin t o block m ore t raffic int o t he net work, t hose who want t o do reconnaissance have t o becom e m ore clever and st ealt hy in t he m anner in which t hey scan, as shown in t his exam ple. Not e t hat t he source port s are t he sam e as t he dest inat ion port s. This is not t he expect ed behavior of t he client select ing an ephem eral port wit h a value great er t han 1023. This is anot her signat ure t hat helps t o ident ify t his scan. Wit h t he lone ACK flag set and ident ical source and dest inat ion port s, we can assum e t hat t his

t raffic has been " craft ed." Som eone has writ t en a program t o execut e t his part icular scan; it is not t he result of norm al TCP/ I P st ack t raffic generat ion.

Re se r ve d Pr iva t e N e t w or k s Throughout t he t ext , you will see references of net works 192.168 and 172.16 as exam ples. These part icular address spaces are part of what t he governing body of t he I nt ernet , t he I nt ernet Address Num bers Aut horit y ( I ANA) , has deem ed t o be reserved privat e net works per RFC 1918. I n ot her words, t hese are address spaces t hat should be used for int ernal net works and t raffic should not be sent t o or from t hese net works. These address spaces are oft en used so t hat a sit e will not exhaust it s act ual assigned addresses. Traffic t o t hese net works is not rout able because t hese are privat e address spaces. When you see t hese address spaces used in exam ples, underst and t hat t hey are being used t o disguise t he real address spaces t hat were scanned or probed. The int ent is not t o im ply t hat t raffic can be rout ed t o t heses net works via t he I nt ernet . A Te lne t Sca n? Look carefully at t he next scan. Short of finding Waldo in t he out put , do you see anyt hing am iss?

scanner.se.45820 scanner.se.45820 scanner.se.52526 scanner.se.45820 scanner.se.52526 scanner.se.45820 scanner.se.52526 scanner.se.52526 scanner.se.52526

> > > > > > > > >

192.168.209.5.23: S 4195942931:4195942935(4) win 4096 192.168.216.5.23: S 4195944723:4195944727(4) win 4096 172.16.68.5.23: S 357331986:357331990(4) win 4096 192.168.183.5.23: S 4196001810:4196001814(4) win 4096 172.16.248.5.23: S 357312531:357312535(4) win 4096 192.168.205.5.23: S 4196007442:4196007446(4) win 4096 172.16.250.5.23: S 357313043:357313047(4) win 4096 172.16.198.5.23: S 357365266:357365270(4) win 4096 172.16.161.5.23: S 357355794:357355798(4) win 4096

To t he naked eye, it is a scan from scanner.se of dest inat ion host s on t he 192.168 and 172.16 subnet s—specifically t o dest inat ion port 23, or t elnet . You m ight conclude t hat t his is an at t em pt t o find all host s on t he dest inat ion subnet s t hat offer t elnet , and t hat would be m ost ly correct . A subt le signat ure m ight indicat e pot ent ially evasive behavior, however. A SYN request usually sends no dat a byt es, but t his scan sends 4 byt es, as you can t ell by looking at t he num ber in t he parent heses. You m ight im agine t hat t he 4 byt es of dat a sent before t he com plet ion of t he t hree- way handshake would be discarded. However, t his is not t he case. The 4 byt es should be included in t he dat a aft er t he handshake has been com plet ed as

not ed by RFC 793. Any payload byt es t hat are sent during t he handshake becom e part of t he dat a st ream aft er t he com plet ion of t he handshake according t o t he RFC. This could be a good way t o circum vent det ect ion by an int rusion- det ect ion syst em ( I DS) t hat exam ines dat a sent only aft er t he t hree- way handshake. I f you see 64 dat a byt es sent on a SYN connect ion t o your DNS server t o t he DNS port 53, t his m ight indicat e a different issue alt oget her. Soft ware known as 3DNS at t em pt s t o give users t he quickest response t im e t o web request s. One way t hat t his is done is by at t em pt ing t o m easure t he response t im e t o your DNS server from one or m ore web servers t hat m ight be used t o respond t o t he user's request . As a represent at ive size of a t ypical web request , 64 byt es are used. I f you see t his act ivit y, it should not be considered st ealt hy; perhaps you m ight deem it invasive or annoying, or even ineffect ive because m any sit es block inbound act ivit y t o TCP port 53, but t he int ent is not m alicious. TCP Se ssion H ij a ck in g Alt hough TCP appears t o be a fairly safe prot ocol because of all t he negot iat ion involved in session est ablishm ent and all t he prot ocol and precision involved in dat a exchange, don't get com placent . Evil sniffers can be set up on an unsuspect ing host t o capt ure TCP or ot her dat a t hat crosses t he sniffers' pat h. Sniffers t hat are placed on net works t hat are not swit ched can snoop clear- t ext dat a such as user I Ds and passwords t hat are not encrypt ed in any way. Session hij acking soft ware, such as Hunt , uses anot her approach t o exploit an exist ing TCP session. These at t em pt t o int ercept an est ablished TCP session and hij ack one end of t he connect ion from t he session t o an evil host . The problem is t hat convent ional TCP exchanges do not require any aut hent icat ion or confirm at ion t hat t hey are t he act ual host s involved in a previously est ablished connect ion. Aft er a session has been est ablished bet ween t wo host s, t hose host s use t he following t o reconfirm t he corresponding host : z z

z

z

I P num ber. The est ablished I P num bers of t he host s m ust not change. Port num bers. Most prot ocols com m unicat e bet ween est ablished port s only; port s do not change. Sequence num bers. Sequence num bers m ust change predict ably in respect t o t he I SN and t he aggregat e num ber of byt es sent from one host t o anot her. Acknowledgem ent num bers. Acknowledgem ent num bers m ust change in respect t o delivered sequence num bers and aggregat e byt es acknowledged from one host t o anot her.

I f a host ile user can observe dat a exchanges and successfully int ercept an ongoing connect ion wit h all t he aut hent icat ion param et ers properly set , he can hij ack a session. I m agine t he dam age t hat can be done if t his hij acked session is one t hat

has root aut horit y. Many com plicat ions and considerat ions are involved in session hij acking. I t is not a t rivial endeavor, but it is m ade sim pler using t he Hunt soft ware.

Su m m a r y A vast and growing num ber of securit y t ools are at your disposal.You have m any t ool choices when it com es t o m onit oring your net work. When you decide which t ool t o use, m ake sure t hat t he t ool provides at least t he level of det ail t hat TCPdum p offers. Adm it t edly, TCPdum p does not provide especially aest het ic out put , but it does give t he required am ount of det ail t o m ake int elligent assessm ent s about t raffic act ivit y. I f you select a t ool t hat is easier on t he eye, but light er on cont ent , you m ight not get t he whole st ory. TCP is t he prot ocol used for applicat ions t hat require reliable delivery. TCP exchanges follow a prescribed archit ect ure of session est ablishm ent , possible dat a t ransfer, and session t erm inat ion, replet e wit h all t he m echanism s t o ensure delivery and receipt of dat a. When you observe TCP act ivit y wit h TCPdum p, you can delve int o t he det ails, if desired or necessary, or you can observe broader pat t erns and m ake m ore general assessm ent s of t he t ype of act ivit y t hat has t ranspired. TCP is a very robust prot ocol, and it has been robust ly m ut at ed for m alicious uses. Carefully analyze it for t he unexpect ed when m onit oring TCP act ivit y. As I nt rusion Det ect ion Syst em s ( I DSs) and firewalls becom e m ore sophist icat ed in funct ion, so do t he hackers' effort s t o circum vent det ect ion and shunning. I t is im port ant for an int rusion analyst t o have a good underst anding of TCP, and TCPdum p is an excellent inst ruct ional t ool.

Ch a pt e r 3 . Fr a gm e n t a t ion

At different t im es, at t ackers use fragm ent at ion bot h t o m ask and facilit at e t heir probes and exploit s. Som e int rusion- det ect ion syst em s and packet - filt ering devices do not support packet reassem bly or perform it correct ly and t herefore do not det ect or block act ivit y where t he signat ure is split over m ult iple dat agram s. Availabilit y or denial- of- service at t acks use highly fragm ent ed t raffic t o exhaust syst em resources. These are som e of t he reasons you m ight want t o learn about fragm ent at ion and som e of t he t opics covered in t his chapt er. By underst anding how t his facet of I P works, you will be equipped t o det ect and analyze fragm ent ed t raffic and discover whet her it is norm al fragm ent at ion versus fragm ent at ion used for ot her purposes. Fragm ent at ion can be a nat urally occurring effect of t raffic t raveling t hrough net works of varying sized m axim um t ransm ission unit s ( MTU) . The t heory and com posit ion of norm al fragm ent at ion is discussed first in t his chapt er t o acquaint you wit h how it should operat e.

Th e or y of Fr a gm e n t a t ion Fragm ent at ion occurs when an I P dat agram t raveling on a net work has t o t raverse a net work wit h a m axim um t ransm ission unit t hat is sm aller t han t he size of t he dat agram . For inst ance, t he MTU or m axim um size for an I P dat agram for Et hernet is 1500 byt es. I f a dat agram is larger t han 1500 byt es and needs t o t raverse an Et hernet net work, it requires fragm ent at ion by a rout er direct ing it t o t he Et hernet net work. Fragm ent at ion can also occur when a host needs t o put a dat agram on t he net work t hat exceeds it s own net work's MTU. Fragm ent s cont inue on t o t heir dest inat ion, where t he dest inat ion host reassem bles t hem . Fragm ent s can even becom e furt her fragm ent ed if t hey cross an MTU sm aller t han t he fragm ent size. Alt hough fragm ent at ion is a perfect ly norm al event , it is possible t o craft fragm ent s for t he purposes of avoiding det ect ion by rout ers and int rusion- det ect ion syst em s t hat don't deal well wit h

fragm ent at ion. What kind of inform at ion m ust t he fragm ent s carry for t he dest inat ion host t o reassem ble t hem back t o t he original unfragm ent ed st at e? The following list answers t his quest ion: z

z

z z

All fragm ent s from t he sam e dat agram m ust be associat ed wit h each ot her fragm ent by using a com m on fragm ent ident ificat ion num ber. This is cloned from a field in t he I P header known as t he I P ident ificat ion num ber, also called t he fragm ent I D. Each fragm ent m ust carry what it s place or offset is in t he original unfragm ent ed packet . Each fragm ent m ust t ell t he lengt h of t he dat a carried in t he fragm ent . Finally, each fragm ent m ust know if m ore fragm ent s follow it . This is done using t he More Fragm ent s ( MF) flag.

Th e Fr a gm e n t I D N u m be r / I P I de n t ifica t ion N u m be r The I P ident ificat ion value is a 16- bit field found in t he I P header of all dat agram s. This uniquely ident ifies each dat agram sent by t he host . Typically, t his value increases by one for each dat agram sent by t hat host . When t he dat agram becom es fragm ent ed, all fragm ent s creat ed from t his dat agram cont ain t his sam e I P ident ificat ion num ber, or fragm ent I D. The following TCPdum p out put shows an I P ident ificat ion num ber of 202 for t his unfragm ent ed out put :

ping.com > 192.168.244.2: icmp: echo request (ttl 240, id 202)

I f t his dat agram were t o becom e fragm ent ed on t he way t o it s dest inat ion, all fragm ent s creat ed from t his dat agram would share a fragm ent I D of 202. This TCPdum p out put was generat ed using t he - vv opt ion. This is a verbose opt ion t hat says t o list t he t im e- t o- live ( TTL) value and t he I P ident ificat ion values at t he end of t he st andard out put . This inform at ion is cont ained in t he I P header. The I P header is placed in an I P dat agram followed by an encapsulat ed fragm ent . As you have learned, all TCP/ I P

t raffic m ust be wrapped wit hin I P because I P is t he prot ocol responsible for get t ing t he packet delivered. Visu a lizing Fr a gm e n t a t ion : Se e in g I s Un de r st a n din g This discussion uses Et hernet as t he exam ple link layer m edium t o dem onst rat e t he packaging of dat agram s. Figure 3.1 depict s t he configurat ion of a dat agram t hat is not fragm ent ed. As previously m ent ioned, a dat agram t raveling on Et hernet has an MTU of 1500 byt es. Each dat agram m ust have an I P header, which is t ypically 20 byt es, but can be m ore if I P opt ions, such as source rout ing, are included. Figu r e 3 .1 . Et h e r n e t da t a gr a m pa ck a gin g.

As a quick refresher, recall t hat t he I P header cont ains inform at ion such as t he source and dest inat ion I P num bers. I t is considered t he " net work" port ion of t he I P dat agram because rout ers use t he inform at ion found in t he I P header t o direct t he dat agram t oward it s dest inat ion. Som e kind of dat a is encapsulat ed aft er t he I P header. This dat a can be an I P prot ocol such as TCP, UDP, or I CMP. I f t his dat a were TCP, for inst ance, it would include a TCP header and TCP dat a. Figure 3.2 shows a dat agram of 4028 byt es. This is an I CMP echo request bound for an Et hernet net work t hat has an MTU of 1500. This is an abnorm ally large I CMP echo request t hat is not represent at ive of norm al t raffic, but it is used t o illust rat e how fragm ent at ion occurs. So, t he 4028 byt e dat agram will have t o be divided int o fragm ent s of 1500 byt es or less. Each of t hese 1500- byt e fragm ent ed packet s will have a 20- byt e I P header like t he init ial fragm ent , leaving 1480 byt es m axim um for dat a for each fragm ent . Figure 3.3 exam ines t his sam e dat agram , but shows t he allocat ion of byt es per fragm ent . The following sect ions exam ine t he cont ent s of each of t he individual t hree fragm ent s. Figu r e 3 .2 . Or igin a l 4 0 2 8 byt e fr a gm e n t br ok e n int o t hr e e fr a gm e nt s of 1 5 0 0 byt e s or le ss.

Figu r e 3 .3 . Byt e a lloca t ion s pe r fr a gm e n t .

All Aboa r d t h e Fr a gm e n t Tr a in

Turn your concent rat ion t o t he init ial fragm ent in t he fragm ent t rain shown in Figure 3.4. The " original" I P header will be cloned t o cont ain t he ident ical fragm ent ident ificat ion num bers for t he first and rem aining fragm ent s. Figu r e 3 .4 . Th e fr a gm e n t e n gin e .

The first fragm ent is t he only one t hat will carry wit h it t he I CMP m essage header. This header is not cloned in subsequent associat ed fragm ent s and t his concept of t he first fragm ent alone ident ifying t he nat ure of t he fragm ent is significant , as you will soon learn. The first fragm ent has a 0 offset , a lengt h of 1480 byt es of lengt h, 1472 byt es of dat a, and 8 byt es of I CMP header; and because m ore fragm ent s follow, t he More Fragm ent s flag is set . Figure 3.5 explains t he configurat ion of t he first fragm ent in t he fragm ent t rain. The first 20 byt es of t he 1500 byt es are t he I P header. The next 8 byt es are t he I CMP header. Rem em ber t hat t his was an I CMP echo request t hat has an 8- byt e header in it s original packet . The rem aining 1472 byt es are for I CMP dat a. Figu r e 3 .5 . Th e gu t s of t h e fr a gm e n t e ngin e .

I n addit ion t o t he norm al fields carried in t he I P header, such as source and dest inat ion I P and prot ocol ( in t his inst ance of I CMP) , t here are fields specifically for fragm ent at ion. The fragm ent I D wit h a value of 21223 is t he com m on link for all t he fragm ent s in t he fragm ent t rain. There is a field known as t he More Fragm ent s flag, which indicat es t hat anot her fragm ent follows t he current one. I n t his first fragm ent , t he flag is set t o 1 t o indicat e t hat m ore fragm ent s do follow.

Also, t he offset of t he dat a cont ained in t his fragm ent relat ive t o t he dat a of t he whole unfragm ent ed dat agram m ust be st ored. For t he first record, t he offset is 0. Finally, t he lengt h of t he dat a carried in t his fragm ent is st ored as t he fragm ent lengt h—in t his fragm ent , t he lengt h is 1480. This is t he 8- byt e I CMP header followed by t he first 1472 byt es of t he I CMP dat a. Th e Fr a gm e n t D in in g Ca r

Take a look at Figure 3.6 t o focus on t he next fragm ent in t he fragm ent t rain. An I P header is cloned from t he " original" header wit h an ident ical fragm ent ident ificat ion num ber, and m ost of t he ot her dat a in t he I P header ( such as t he source and dest inat ion num bers) is replicat ed for t he new header. Em bedded aft er t his new I P header is 1480 I CMP dat a byt es. As you can see, t he second fragm ent has an offset of 1480 and a lengt h of 1480 byt es; and because one m ore fragm ent follows, t he More Fragm ent s flag is set . Figu r e 3 .6 . The fr a gm e n t din in g ca r .

Cont inuing wit h fragm ent at ion in Figure 3.7, you can exam ine t he I P dat agram carrying t he second fragm ent . As wit h all fragm ent s in t his fragm ent t rain, it requires a 20- byt e I P header. Again, t he prot ocol in t he header indicat es I CMP. The fragm ent ident ificat ion num ber rem ains 21223. And, t he More Fragm ent s flag is t urned on because anot her fragm ent follows. The offset is 1480 byt es int o t he dat a port ion of t he original I CMP m essage dat a. The preceding fragm ent occupied t he first 1480 byt es. This fragm ent is 1480 byt es long as well, and it is com posed ent irely of I CMP dat a byt es. Figu r e 3 .7 . Th e gu t s of t h e fr a gm e n t dinin g ca r .

I t is wort h repeat ing t hat t he I CMP header in t he first fragm ent does not get cloned along wit h t he I CMP dat a. This m eans t hat if you were t o exam ine t his fragm ent alone, you could not t ell t he t ype of t he I CMP m essage—in t his case, an I CMP echo request . This becom es an im port ant issue wit h regard t o packet filt ering devices ( as discussed lat er in t his chapt er) . Th e Fr a gm e nt Ca boose

Exam ine t he final fragm ent in t he fragm ent t rain in Figure 3.8. Again, an I P header is cloned from t he " original" header wit h an ident ical fragm ent ident ificat ion num ber, and ot her fields are replicat ed for t he new header. The final 1048 I CMP dat a byt es are em bedded in t his new I P dat agram . You see t he t hird fragm ent has an offset of 2960 and a lengt h of 1048 byt es; and because no m ore fragm ent s follow, t he More Fragm ent s flag is 0. Figu r e 3 .8 . Th e fr a gm e n t ca boose .

Figure 3.9 depict s t he last fragm ent in t he fragm ent t rain. Again, 20 byt es are reserved for t he I P header. The rem aining I CMP dat a byt es are carried in t he dat a port ion of t his fragm ent . The fragm ent I D is 21223, and t he More Fragm ent s flag is not set because t his is t he last fragm ent . The offset is 2960 ( t he sum of t he t wo

1480- byt e previous fragm ent s) . Only 1048 dat a byt es are carried in t his fragm ent com prised ent irely of t he rem aining I CMP m essage byt es. This fragm ent , like t he second one, has no I CMP header and t herefore no I CMP m essage t ype t o reflect t hat t his is an I CMP echo request . Figu r e 3 .9 . Th e gu t s of t h e fr a gm e n t ca boose .

Vie w in g Fr a gm e n t a t ion Usin g TCPdu m p Take a look at t he following TCPdum p out put . As you can see, t he t hree different records represent t he t hree fragm ent s discussed earlier. This m eans t hat t he host running TCPdum p has collect ed t he I CMP echo request aft er t he fragm ent at ion occurred. Here are t he records:

ping.com > myhost.com: icmp: echo request (frag 21223:1480@0+) ping.com > myhost.com: (frag 21223:1480@1480+) ping.com > myhost.com: (frag 21223:1048@2960

The first line shows ping.com sending an I CMP echo request t o m yhost .com . The reason t hat TCPdum p can ident ify t his as an I CMP echo request is because t he first fragm ent cont ains t he 8- byt e I CMP header t hat ident ifies t his as an I CMP echo request . Now, look at t he fragm ent at ion not at ion at t he right side of t he record. TCPdum p convent ion for displaying fragm ent ed out put is t hat t he word frag appears, followed by t he fragm ent I D ( 21223, in t his exam ple) , followed by a colon. The lengt h of dat a in t he current fragm ent follows, 1480, followed by an at ( @) sign, and t hen you see t he offset int o t he dat a ( 0, because t his is t he first fragm ent ) . The plus ( + ) sign indicat es t hat t he More Fragm ent s flag is set . This fragm ent knows t he purpose of t he t raffic, knows it is t he first fragm ent , knows t hat m ore fragm ent s follow, but doesn't know what or how m any follow. The second record differs som ewhat . Not ice t hat t here is no I CMP echo request label. This is because t here is no I CMP header t o t ell what kind of I CMP t raffic t his is. The I P header will st ill have t he prot ocol field set t o I CMP, but t hat is all you

can t ell looking at t his fragm ent alone. You see t he TCPdum p out put list s t he fragm ent I D of 21223, t he current dat a lengt h of 1480, and t he offset of 1480. The plus sign signifies t hat t he More Fragm ent s flag is set . This fragm ent has an affiliat ion, a follower, and a sense of placem ent , but is essent ially clueless about it s purpose—sounds like freshm an year at college. The last line is very sim ilar t o t he second one in form at . I t shows t he sam e fragm ent I D of 21223, it has a lengt h of 1048, and a displacem ent of 2960. No More Fragm ent s flag appears in t he final record, however, as you would expect . This fragm ent has an affiliat ion, no sense of purpose, and no followers.

H ow t h e Fr a gm e n t Offse t I s St or e d Alt hough TCPdum p nicely com put es t he fragm ent offset for you, it is st ored in t he packet different ly. Be forewarned t hat if you ever exam ine a fragm ent offset in a packet —perhaps from a TCPdum p hex dum p—you will need t o do som e m anipulat ion before arriving at t he act ual byt e offset . The fragm ent offset is found in part of t he sixt h byt e and t he ent ire sevent h byt e offset of t he I P header. I t is a 13- bit field t hat can represent a m axim um value of 8191 ( 2 13 – 1) . Yet , t heoret ically, t hough rarely indicat ive of norm al fragm ent at ion, t he offset can be great er t han 8191 because t he m axim um dat agram size is 65,535 ( 2 16 – 1) byt es. To represent t he offset value found in t he packet as byt es, m ult iply it by 8. For t hose of you who want t o know t he m at hem at ical origin of t his, 65,536 ( 2 16 ) divided by 8192 ( 2 13 ) is 8. Fr a gm e n t a t ion a n d Pa ck e t - Filt e r in g D e vice s This sect ion covers fragm ent at ion and how a packet - filt ering device, such as a rout er or firewall, m ight deal wit h it . The problem arises when such a device at t em pt s t o block fragm ent ed t raffic. Because only t he first fragm ent of a fragm ent t rain will cont ain any kind of prot ocol header such as TCP, UDP, or I CMP, only t his fragm ent is prevent ed from ent ry int o t he net work guarded by a packet - filt ering device incapable of exam ining st at e of a header field. What I m ean by st at e is it appears obvious t o you t hat any fragm ent sharing t he fragm ent I D of t he blocked one should also be blocked. But , som e packet - filt ering devices don't m aint ain t his inform at ion. They m yopically look at each fragm ent as an individual ent it y and don't connect it wit h previous or subsequent packet s. I nt uit ively enough, t his is not a part icularly good archit ect ure, so why is it used? Think about t he overhead required t o m aint ain st at e. I t m eans t hat each fragm ent m ust be exam ined and st ored; t his is expensive in t erm s of t im e, processing, and m em ory. Event ually, fragm ent s m ust be allowed or rej ect ed

access and t hat t oo consum es m ore resources. I t is far sim pler t o have an at om ic archit ect ure t hat scrut inizes on a per- packet basis. I f a part icular packet doesn't m at ch t he blocking crit eria, in t his inst ance, because of t he absence of a prot ocol header, it is allowed int o t he net work. Fragm ent ed TCP or UDP dat agram s m ight cont ain t heir respect ive header inform at ion in t he first fragm ent only. Blocking decisions are oft en based on header inform at ion, such as TCP or UDP dest inat ion port s. This m eans t hat fragm ent ed TCP and UDP are suscept ible t o t he sam e short com ings of a st at eless packet - filt ering device. One final point t o rem em ber is t hat I P is not a reliable prot ocol, and it is very possible for t he first fragm ent t hat cont ains t he prot ocol header inform at ion t o be lost . When t his occurs, t he packet - filt ering device has an even m ore difficult j ob of allowing or denying t raffic. I n fact , if one of t he fragm ent s does not arrive at t he dest inat ion, all m ust be resent . Th e D on 't Fr a gm e n t Fla g I n som e of t he TCPdum p out put you have looked at , you m ight have seen t he let t ers DF in parent heses. This m eans t he Don't Fragm ent flag is set . No sur- prises here; as t he nam e im plies, if t his flag is set , fragm ent at ion will not be done on t he dat agram . I f t his flag is set and t he dat agram crosses a net work where fragm ent at ion is required, t he rout er discovers t his, discards t he dat agram , and sends an I CMP " unreachable—need t o frag" error m essage back t o t he sending host . The I CMP error m essage cont ains t he MTU of t he net work t hat required fragm ent at ion. Som e host s int ent ionally send an init ial dat agram across t he net work wit h t he DF flag set as a way t o discover t he pat h MTU for a part icular source t o dest inat ion host . I f t he I CMP error m essage is ret urned wit h t he sm aller MTU, t he host t hen packages all dat agram s bound for t hat dest inat ion in sm all enough unit s t o avoid fragm ent at ion. This is oft en used wit h TCP because TCP requires a lot of overhead. Fragm ent at ion can int roduce ineffi- ciency because if one fragm ent is lost , all m ust be sent again; t hat is one reason it is desirable t o avoid fragm ent at ion. As you can surm ise, a m alicious user also can use t his m echanism t o discover t he MTU of a segm ent of your net work t o be used lat er for fragm ent at ion exploit s. The user could craft dat agram s wit h different lengt hs and t he DF flag set and observe when an I CMP error m essage is received. This assum es t hat t he t arget ed net work doesn't disable t he I CMP error m essage from being sent . The following TCPdum p out put shows an I CMP m essage in which a rout er discovered t hat fragm ent at ion was necessary, but t he Don't Fragm ent flag was set .

router.ru > mail.mysite.com: icmp: host.ru unreachable - need to frag (mtu 308) (DF)

The st im ulus for t his reply was t hat m ail.m ysit e.com at t em pt ed t o send a dat agram larger t han 308 byt es t o host .ru wit h t he DF flag set before t his packet was sent . rout er.ru finds t hat t he dat agram m ust t raverse a sm aller net work wit h an MTU of 308 byt es and fragm ent at ion is necessary. When rout er.ru exam ines t he record, it finds t hat t he Don't Fragm ent flag is set and an I CMP m essage is sent back t o m ail.m ysit e.com inform ing it of t he problem . Now, m ail.m ysit e.com eit her m ust package t he dat agram s t o be sm aller t han t he MTU of 308 so t hat fragm ent at ion doesn't occur or it m ust rem ove t he DF flag so t hat fragm ent at ion can occur and t hen resend t he dat agram .

M a liciou s Fr a gm e n t a t ion There is no rest for t he weary analyst when it com es t o m alicious fragm ent at ion. Fragm ent at ion, it seem s, has provided a field day of play and plunder for t he hackers, and t hey have produced a bevy of at t acks. This advice is repeat ed for ot her prot ocols and at ot her t im es in t his book, but be especially alert and wat chful when analyzing fragm ent at ion. Som e of t he best analyst s I know have been m ockingly accused of paranoia by envisioning everyone at t acking t heir net works in every different way. Well, I would like t o invit e you t o j oin t he m isfit s' bandwagon of paranoia when it com es t o fragm ent at ion. I f your I DS cannot be t uned t o give special scrut iny t o fragm ent at ion, you m ight be m issing a chunk of t he act ion. I f your I DS can correct ly m aint ain st at e, reassem ble fragm ent s, and t hen m ake som e kind of int elligent assessm ent , you appear t o be well- arm ed. One of t he m ost infam ous denial- of- service at t acks associat ed wit h fragm ent at ion, Ping of Deat h, is discussed in Appendix B, " Denial of Service." The next sect ions exam ine a couple of ot her fragm ent at ion at t acks. TCP H e a de r Fr a gm e n t s nm ap is an excellent scanning t ool t hat runs on m any UNI X plat form s and is available from www.insecure.org/ nm ap. I t does convent ional port scanning t o discover what port s are open on a t arget host and does st ealt h scanning t hat looks for open port s, but also m akes an att em pt t o elude det ect ion by int rusiondet ect ion syst em s. An nm ap com m and- line opt ion ( - f) fragm ent s t he 20- byt e TCP headers in m ult iple fragm ent s in an at t em pt t o avoid det ect ion. The following TCPdum p out put was generat ed using t he com m and:

nmap -f -sS -p 53

target.com

This sends a fragm ent ed SYN connect ion t o port 53 of t arget .com :

truncated-tcp fragger.org > truncated-tcp fragger.org > truncated-tcp fragger.org >

16 (frag 25096:16@0+) target.com: (frag 25096:4@16) 16 (frag 4265:16@0+) target.com: (frag 4265:4@16) 16 (frag 34927:16@0+) target.com: (frag 34927:4@16)

The preceding TCPdum p out put shows a scan t hat fragm ent ed t he TCP header. This is a scan from fragger.org t hat scanned port 53 on t arget .com using a st andard TCP SYN request . This is not obvious, however, because of t he sm all fragm ent s involved. Looking at t he first line of dat a, you see a fragm ent wit h 16 byt es of t runcat ed TCP dat a. The m inim um TCP header is 20 byt es wit h no opt ions. Because t his is not a com plet e TCP header, TCPdum p report s t his as truncated-tcp. I n t he next record, t he addit ional 4 byt es of TCP header are sent . I t is possible t hat an int rusiondet ect ion syst em m ight not capt ure or report t his kind of st ealt h scan. Te a r dr op Now t hat you are fam iliar wit h t he way fragm ent at ion should work, t ake a look at t he following TCPdum p out put . See if you can det ect a problem wit h t he fragm ent at ion generat ed by a m alicious program known as Teardrop:

evilfrag.com.139 > target.net.139: udp 28 (frag 242:36@0+) evilfrag.com > target.net: (frag 242:4@24)

The first fragm ent delivered is a UDP dat agram t hat has a fragm ent I D of 242, a lengt h of 36 dat a byt es, and an offset of 0. This is represent ed in Figure 3.10 by t he pat t erned rect angles. I t spans byt es 0 t hrough 35, inclusive. Figu r e 3 .1 0 . Te a r dr op fr a gm e n t m u t a t ion .

Now, t he second fragm ent com es along. I t is associat ed wit h t he first fragm ent because of fragm ent I D of 242, it has a lengt h of 4, and it begins at an offset of 24 byt es int o t he dat a port ion. I t is depict ed in Figure 3.10 in t he solid color in t he m iddle. As you can see, it act ually overlaps byt es 24 t hrough 27 of t he first fragm ent .

The Teardrop at t ack exploit s weaknesses in t he reassem bly process of fragm ent s. The Teardrop program creat es fragm ent s wit h overlapping offset fields. When t hese fragm ent s are reassem bled at t he dest inat ion host , som e syst em s will crash, hang, or reboot . This at t ack was first report ed in 1997, yet it provides a good exam ple of how m alform ed fragm ent s can wreak havoc on a t arget host . A m alform ed or an incom plet e set of fragm ent s st ill present s problem s for som e host s. More recent ly, a program known as Jolt 2 t hat will be discussed in m ore det ail in Chapt er 5, " St im ulus and Response," can cause a denial of service via resource st arvat ion sim ply by repeat edly sending a non- zero offset fragm ent t o Windows host s as recent as Windows 2000. So m any problem s exist because host s, rout ers, and int rusion- det ect ion syst em s have t o deal wit h m any aspect s of fragm ent at ion. First , t hey have t o m ake sure t hat all t he fragm ent s in a fragm ent t rain are received. Second, t hey have t o m ake sure t hat t hey are properly form at t ed—none m ay overlap—and in aggregat e, t hey m ay not exceed t he m axim um dat agram size of 65,535. Finally, t hey m ust check t hat no shenanigans are at t em pt ed by fragm ent ing prot ocol headers. This is a t all order because it requires fragm ent reassem bly and det ect ion of m ut at ions. To do t his correct ly, t his requir es a com m it m ent of m em ory and allocat ion of CPU power, and if not im plem ent ed correct ly, it can cause denial of service or ot her problem s.

An a lyzin g Fr a gm e n t a t ion Believe it or not , fragm ent at ion is not really so com plicat ed aft er you underst and a lit t le t heory and get com fort able wit h t he not at ion associat ed wit h it . Many t im es as a net work analyst , in t he process of exam ining TCPdum p out put , I have gone t hrough t he m ent al exercise of " what 's wrong wit h t his fragm ent at ion?" I t is m ore t han an academ ic skill; it is required t heory in your arsenal of knowledge t o analyze t raffic on your net work and safeguard it against fragm ent at ion t ypes of exploit s. I f you do discover som e kind of genuine m ut ant fragm ent at ion, you m ight experience an init ial and well- deserved feeling of t rium ph. But , realize t hat t he discovery is j ust t he first st ep in unraveling t he m yst ery. Next , you have t o figure out what t he int ended purpose of t he weird fragm ent at ion is, and t his is not always obvious. One com m on explanat ion is som e kind of denial of service, eit her a degradat ion of service or an out right disabling of t he t arget host . Ot her explanat ions are t o evade det ect ion or circum vent shunning by m onit oring or filt ering devices incapable of fragm ent reassem bly. Take a look at what is happening on t he net work in general and t he t arget host specifically t o m ake your assessm ent . Finally, if you t hink t hat your sit e is well- prot ect ed at t he perim et er and you don't have a firewall or filt ering rout er t hat is st at eful, t hink again!

Wit h such a gaping hole, it is alm ost t rivial for even an inexperienced int ruder t o bypass your weak defense.

Su m m a r y Norm al fragm ent at ion involves separat ing and packaging t he original dat agram int o new packet s less t han or equal t o t he size of a sm aller MTU. Each new fragm ent becom es a packet of it s own wit h a new I P header consist ing of m any cloned fields ( I P num bers, I P ident ificat ion num ber, and so on) from t he I P header of t he original unfragm ent ed dat agram . However, each new fragm ent will cont ain som e unique ident ifying inform at ion such as t he offset int o t he fragm ent t rain, t he num ber of dat a byt es in t he fragm ent , and whet her m ore fragm ent s follow. Malicious fragm ent at ion com es in m any different form s. Ult im at ely, t he purpose m ight be a denial of service or an opport unit y t o sneak som e t raffic int o a net work t hat m ight norm ally block an unfragm ent ed incarnat ion of t his t raffic. Som e packet - filt ering devices do not handle fragm ent at ion well, if at all, allowing t hese fragm ent s ent ry int o t he net work. By having an appreciat ion and underst anding of fragm ent at ion, in general, you will be bet t er able t o det ect m alicious fragm ent at ion and recognize norm al fragm ent at ion.

Ch a pt e r 4 . I CM P

I nt ernet Cont rol Message Prot ocol ( I CMP) was conceived as an innocuous m et hod of report ing error condit ions and issuing and responding t o sim ple request s. Perhaps because of it s seem ingly benign origins, som e of t he current m ut at ions of I CMP for less- t han- upst anding purposes seem all t he m ore out rageous. I n it s pure st at e, I CMP is supposed t o be a relat ively sim ple and chast e prot ocol, but it has been alt ered t o act as a conduit for evil purposes. Therefore, it is im port ant t o underst and how t his prot ocol is used bot h for it s int ended purposes and for m alicious purposes. This chapt er exam ines several aspect s of I CMP. First , you are int roduced t o som e background about I CMP followed by how I CMP is used t o find live host s on a t arget net work. Next , you learn about bot h t he expect ed and unexpect ed uses of I CMP t hat you m ight see in your own net work. You t hen put t his I CMP t heory int o act ion by analyzing som e unusual det ect ed I CMP act ivit y. Finally, t he discussion focuses on prot ect ing your net work by blocking inbound I CMP act ivit y and t he accom panying repercussions of doing so.

I CM P Th e or y Before delving int o exam ples of I CMP t raffic, let 's flesh out I CMP a lit t le by giving it som e foundat ion and perspect ive. I f you are already fam iliar wit h t he t heory of I CMP, or if t he sound of I CMP t heory isn't high on your quiver quot ient , you can skip t o t he sect ion, " Mapping Techniques," and ping away. W h y D o You N e e d I CM P? As you will recall from Chapt er 2, "I nt roduct ion t o TCPdum p and TCP," TCP is a connect ion- orient ed prot ocol wit h lot s of overhead involved in ensuring reliable delivery. User Dat agram Prot ocol ( UDP) is a connect ionless prot ocol t hat doesn't prom ise reliable delivery. Bot h UDP and TCP require a server port wit h which a

client can com m unicat e. A sim ple request such as det erm ining whet her a host is alive, com m only known as ping, doesn't need port s t o com m unicat e and doesn't require reliable delivery. This request and several m ore use I CMP t o deliver and respond t o such t raffic. I n addit ion, what if som e kind of error condit ion is discovered by a rout er or a host , and t hat rout er or host needs t o inform a sending source host of t he problem ? Because TCP is a m ore robust prot ocol, it handles som e error condit ions such as a nonlist ening port by sending back a TCP response wit h t he TCP flags of RESET/ ACK set . I f a TCP client or server receives t oo m uch inform at ion, it also has a m echanism t o close down t he receiving buffer by set t ing a window size of 0. This indicat es t hat t he receiving host cannot accept any m ore dat a unt il t he current buffered dat a is processed. However, UDP and I P aren't robust enough t o com m unicat e error condit ions. I f a UDP port is not list ening or t oo m uch dat a is sent t o a list ening port , UDP has no way t o convey t hese condit ions. That is where I CMP com es in: I t provides a sim ple m eans of com m unicat ing bet w een host s or a rout er and a host t o alert t hem t o som e kind of problem sit uat ion. W h e r e D oe s I CM P Fit I n ? The TCP/ I P I nt ernet layering m odel discussed in Chapt er 1, " I P Concept s," is one represent at ion of t he different layers t hat form dat a and pass t he dat a bet ween host s. Figure 4.1 illust rat es t his. Figu r e 4 .1 . TCP/ I P I n t e r n e t m ode l.

St art ing at t he t op, you can see t he high- level applicat ion layer act ivit y t hat m ight represent a TCP/ I P applicat ion such as t elnet . Next is t he t ransport layer, wit h such prot ocols as TCP and UDP t hat provide t he end- t o- end com m unicat ion bet ween host s. Beneat h t hat is t he I nt ernet layer, which is responsible for get t ing t he dat agram from source t o dest inat ion. Finally, t here is t he net work layer, which t ransm it s t he dat agram s over t he net work.

You can see from t his t hat I CMP is in t he sam e net work layer as I P. I CMP is encapsulat ed in t he I P dat agram aft er t he I P header, but it is st ill considered t o be in t he sam e layer as I P. Un de r st a n din g I CM P I CMP differs from TCP and UDP in several ways. For st art ers, I CMP has no port num bers like t hose found in t he t ransport layer prot ocols UDP or TCP. The closest t hing t hat I CMP has t o a different iat ion in services is an I CMP m essage t ype and code, t he first 2 byt es in t he I CMP header. These byt es t ell t he funct ion of t he part icular I CMP m essage.

I CM P Type s List ing and exploring all t he variat ions of I CMPs is beyond t he scope of t his book. However, www.iana.org/ assignm ent s/ icm p- param et ers is a great reference for t hose who want t o know m ore about t his t opic. Next , t here is really no such t hing as a client and server. I n fact , when I CMP error m essages are delivered, t he receiving host m ight respond int ernally but m ight not com m unicat e anyt hing back t o t he inform er. I CMP also gives no guarant ees about t he delivery of a m essage. One of t he unusual t rait s about I CMP is t hat services or port s do not have t o be act ivat ed or list ening. Just about every operat ing syst em can respond t o an I CMP echo request ( ping) . The hard part is t urning off t he default behavior of responding t o an I CMP echo request . Anot her unique t rait about I CMP is t hat it support s broadcast t raffic. TCP required an exclusive client / server unicast relat ionship, but I CMP isn't nearly as exclusive. As t he " Sm urf At t ack" sect ion of t his chapt er shows, I CMP's willingness t o respond t o broadcast t raffic som et im es can cause problem s. A host uses I CMP for sim ple replies and request s, and it uses I CMP t o inform anot her host of som e kind of error condit ion. For inst ance, a receiving host m ight have a problem keeping up wit h t he t raffic t hat t he sending host is delivering t o it . One of t he ways t hat a host can inform a sending host t o t hrot t le down t he delivery rat e is t o send it an I CMP source quench m essage. I CMP is used as a m echanism by rout ers t o inform a sending host of som e kind of problem . A rout er m ight deliver an I CMP " adm in prohibit ed" m essage t o a sending host . This m eans t hat t he sending host at t em pt ed t o send som e kind of t raffic t hat was forbidden by an access cont rol list st at em ent of a rout er int erface. I n a sit uat ion such as t his, you would expect t he rout er t o be t he sender of t he m essage because it is t he one forbidding t he act ivit y. However, a rout er also

m ight int ervene t o inform a sending host about a condit ion when a dest inat ion host cannot respond. I f t he dest inat ion host is unreachable, for exam ple, t he dest inat ion host can obviously not respond. I n t his inst ance, t he rout er m ight reply inst ead. Alt hough a rout er m ight t ry t o be helpful by inform ing t he sending host of a problem , it also is providing inform at ion t hat could be used for reconnaissance purposes. The sender t hen could glean som e knowledge about t he t ype of act ivit y t hat t he rout er report s. A good securit y pract ice is t o silence a rout er by prevent ing it from issuing I CMP unreachable m essages t o preclude t he dissem inat ion of unnecessary inform at ion. This will be discussed in m ore det ail in t he sect ion, " Host Unreachable." Su m m a r y of I CM P Th e or y Let 's quickly sum m arize what you've learned in t his short sect ion on I CMP t heory. You have learned t hat I CMP is a m eans of delivering error m essages bet ween host s. I t is encapsulat ed in an I P header, but is considered part of t he I P or I nt ernet layer. I CMP is a unique prot ocol because it doesn't use port s t o com m unicat e like t he t ransport prot ocols do. I CMP m essages can get lost and not be delivered. I n addit ion, I CMP can be broadcast t o m any host s because t here is no sense of an exclusive connect ion. Finally, host s and rout ers are t he senders of I CMP m essages. Host s list en for I CMP, and m ost will respond unless t hey deliberat ely have been alt ered for silence.

M a ppin g Te ch n iqu e s Mapping a t arget net work is a very st rat egic part of m ost int elligent ly planned at t acks. This init ial st ep in reconnaissance at t em pt s t o discover t he live host s in a t arget net work. An at t acker t hen can direct a m ore focused scan or exploit t oward live host s only. I f m apping is not done and a m alicious user or program at t acks a net work, t he at t ack can becom e very noisy by generat ing a lot of t raffic on t he t arget net work and not be very product ive. The lat t er quart er of 1999 saw an exam ple of t his kind of bull- in- a- china shop reckless scan. A Troj an nam ed RingZero t hat infect ed Windows host s appeared t o scan foreign host s for open Web proxy port s. One of t he short com ings of t he RingZero scanning act ivit y was t hat it appeared t o scan random host s on m any net works. I n doing so, m any I P addresses t hat were not act ive were scanned along wit h t he act ive ones. This was a noisy scan for int rusion- det ect ion syst em s t hat saw it . Also, a lot of work had t o be done t o

receive any valuable feedback about host s t hat support ed open Web proxy port s. This would have been a m ore direct ed and perhaps m ore inform at ive scan if t he I P num bers t hat were scanned had been live host s.

Th e Ubiqu it ou s Rin gZe r o Tr oj a n The observed RingZero at t ack in a m onit ored net work involved m any different source I Ps scanning m ost ly inact ive TCP port s: 3128 ( squid proxy server) , 80 ( norm al HTTP port ) , and 8080 ( an alt ernat ive HTTP port ) . About half a dozen of t hese scans were det ect ed on a Class B subnet every hour. Many ot her sit es all over t he world t hat were capable of det ect ing t his act ivit y report ed seeing it , t oo. An init ial t heory was t hat all t his act ivit y was com ing from spoofed source I Ps wit h an unknown int ent . However, Ron Marcum , a syst em adm inist rat or at Vanderbilt Universit y, discovered a Windows host in his net work t hat was doing t his kind of scanning and capt ured t he soft ware called RingZero. At t he Syst em Adm inist rat ion, Net working, and Securit y ( SANS) conference in Oct ober 1999, t he RingZero soft ware was dissect ed. When act ivat ed in a t est net work, t he host on which it was inst alled began t o scan random host s for t he Web proxy port s. I f open Web proxy server port s were discovered, t hey were sent back t o an ft p sit e t hat aggregat ed t his inform at ion for t he collect or. I t is assum ed t hat t he collect or t hen planned t o use t his knowledge for som e fut ure plundering. To dat e, we st ill see RingZero scanning act ivit y and it is st ill unknown what t he infect ion m et hod is and how an infect ed host select s t he I P num bers t o scan for proxy port s. One of t he m ost com m on m et hods of m apping is t o issue I CMP echo request s. A host ( or host s) responds t o an I CMP echo request wit h an I CMP echo reply t o signal it is a live host . This is what t he ping com m and does; it issues an I CMP echo request and wait s for an I CMP echo reply. Many securit y and net work adm inist rat ors have responded t o t his invasive I CMP scrut iny wit h t he knee- j erk react ion of blocking I CMP echo request s. This is a good and necessary react ion, but t his is only a part ial solut ion because it is only a m inor im pedim ent t o t he insist ent pursuer. Blocking I CMP echo request s has m ot ivat ed hackers t o invent ot her scanning m et hods using ot her prot ocols. I n Chapt er 2, t he sect ion, " An ACK Scan," showed how TCP scans can use t he ACK flag t o at t em pt t o ident ify live host s. This can be used as an alt ernat ive net work scanning m et hod t hat blocks I CMP echo request s. The next sect ions look at som e of t he convent ional and esot eric m apping t echniques used. Tir e le ss M a ppe r

The following scan shows t he classic m apping t echnique of sending individual I CMP echo request s t o all host s in a given subnet . I n t his case, t he 192.168.117 Class C subnet is scanned for all live host s. As you can see, t his is a very noisy scan:

00:05:58.560000 00:06:01.880000 00:12:45.830000 00:15:36.210000 00:15:58.600000 00:18:51.650000 00:20:42.750000 00:26:36.680000 00:27:30.620000

scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net

> > > > > > > > >

192.168.117.233: icmp: echo request 192.168.117.139: icmp: echo request 192.168.117.63: icmp: echo request 192.168.117.242: icmp: echo request 192.168.117.129: icmp: echo request 192.168.117.98: icmp: echo request 192.168.117.177: icmp: echo request 192.168.117.218: icmp: echo request 192.168.117.168: icmp: echo request

I f a sit e doesn't specifically look for I CMP act ivit y, however, t his m ight go unnot iced. So, t he age- old philosophical quest ion becom es, if a hacker m aps your ent ire net work and no one is list ening, does it m ake any noise? Alarm ing on individual I CMP echo request s likely would generat e a lot of alert s from an I DS, so I DSs usually do not issue alert s for individual I CMP echo request s. Yet , an I DS t hat exam ines m ore generic scan act ivit y t hat exhibit s a one- t o- m any source- t odest inat ion I P relat ionship would correct ly t rigger on such a scan. I n ot her words, if t he I DS looks for one source I P connect ing t o m any different dest inat ion I Ps in a given t im e period—for inst ance, seven connect ions per hour—it would discover t he preceding scan. Efficie n t M a ppe r Most likely, t he preceding scan was aut om at ed so t hat it wasn't a labor- int ensive effort for t he not - so- wily scanner. But why bot her wit h all t he volum e if I CMP is a prot ocol t hat can be sent t o a broadcast address and can ping m any host s wit h a couple of com m ands? That is what t he following scanner at t em pt s:

13:51:16.210000 13:51:17.300000 13:51:18.200000 13:51:18.310000 13:51:19.210000 13:53:09.110000 13:53:09.940000 13:53:10.110000 13:53:10.960000 13:53:10.980000

scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net

> > > > > > > > > >

192.168.65.255: icmp: echo request 192.168.65.0: icmp: echo request 192.168.66.255: icmp: echo request 192.168.66.0: icmp: echo request 192.168.67.255: icmp: echo request 192.168.67.0: icmp: echo request 192.168.68.255: icmp: echo request 192.168.68.0: icmp: echo request 192.168.69.255: icmp: echo request 192.168.69.0: icmp: echo request

I t appears t hat t he scanner is at t em pt ing t o m ap t he 192.168 subnet . The t hird oct et in t he I P num ber changes from 65 t o 69 in t his excerpt from a larger scan. You can see t he final oct et fluct uat e bet ween 0 and 255. The 255 in t he final oct et is t he classic broadcast address. The 0 in t he final oct et is a broadcast address for

host s t hat have a TCP/ I P st ack based on t he UNI X Berkeley Soft ware Dist ribut ion ( BSD) operat ing syst em . Using bot h t hese broadcast addresses, all live host s in an accessible net work should respond. This should convince you t o deny int o your net work any act ivit y dest ined for t hese broadcast addresses. I don't know of any legit im at e act ivit y for t raffic dest ined for broadcast addresses except for diagnost ic act ivit y. The sect ion, " Sm urf At t ack," shows t hat disallowing t his act ivit y prevent s Sm urf am plificat ion by your net work. Cle ve r M a ppe r I n exam ining t he next scan, you can see a new variat ion on an old m apping schem e:

06:34:31.150000 06:34:31.150000 06:34:31.150000 06:34:31.150000 06:34:31.160000 06:34:31.160000 06:34:31.160000 06:34:31.160000

scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net scanner.net

> > > > > > > >

192.168.21.0: icmp: echo request 192.168.21.63: icmp: echo request 192.168.21.64: icmp: echo request 192.168.21.127: icmp: echo request 192.168.21.128: icmp: echo request 192.168.21.191: icmp: echo request 192.168.21.192: icmp: echo request 192.168.21.255: icmp: echo request

Look at t he scanning pat t ern. You can see t hat I CMP echo request s are being sent t o t he Class C subnet of 192.168.21. Now look at t he final oct et of t he I P address. You can see t hat t he first request is sent t o t he 0 broadcast address, and t he last one is sent t o t he 255 broadcast address. This isn't new; you saw t his in t he preceding scan. Not ice in t he final oct et of t he ot her I P num bers, however, t hat t hey seem t o span 64 I P num bers. For inst ance, t he first I P num ber has a final oct et of 0, and t he following one has a final oct et of 63. That is 64 t ot al I P addresses. What is t he significance of 64? Well, a t ypical Class C subnet has 256 addresses bet ween t he 0 and 255 range. I t is possible t o subdivide a Class C net work so t hat you have m ult iple sm aller net works by assigning an appropriat e subnet m ask. One way t o do t his is t o have four individually addressable subnet s wit h 64 host s each. I n t his schem e, t he net work and broadcast addresses change accordingly. The net work and broadcast addresses for t hose four subnet s are t he I P num bers t hat you see in t he scan. So, it t urns out t hat t he scanner believes t hat t his scanned net work m ight have a different addressing schem e t han t he Class C " nat ural" division. I f t his were t ruly t he addressing schem e for t he 192.168.21 subnet , all live host s m ight respond. Even if t he subnet is a st andard Class C and t he act ivit y is not blocked, t his will st ill ping all host s on t he net work because it uses t he .0 and .255 broadcast addresses. I f you need a refresher about address classes, reference t he " Logical Addresses, I P Addresses" sect ion in Chapt er 1.

Ce r e br a l M a ppe r One final scan shows a different m apping t echnique using anot her I CMP request t ype. The I CMP address m ask request queries a host for t he subnet m ask of t he net work on which it resides. Rem em ber all t he t rouble t hat t he preceding scanner went t hrough t o t ry t o det erm ine t he addressing schem e? That could have been avoided ent irely by using t he following I CMP address m ask request :

20:39:38.120000 20:39:38:170000 (DF) 20:39:39.090000 20:39:39:230000 (DF) 20:39:40.090000 20:39:40:510000 (DF)

scanner.edu > router.com: icmp: address mask request (DF) router.com > scanner.edu: icmp: address mask is 0xffffff00 scanner.edu > router2.com: icmp: address mask request (DF) router2.com > scanner.edu: icmp: address mask is 0xffffff00 scanner.edu > routerx.com: icmp: address mask request (DF) routerx.com > scanner.edu: icmp: address mask is 0xffffff00

This is not a classic m apping t echnique per se, but it can provide som e init ial reconnaissance. The quest here is t o exam ine t he subnet m ask of different rout ers. Typically, only rout ers respond t o address m ask request s so t he scanner m ight discover addit ional reconnaissance of t he repliers. As discussed in Chapt er 1, t he subnet m ask assigned t o a com put er syst em t ells it how m any bit s in it s I P address designat e t he net work and how m any designat e t he host . I f a scanner can det erm ine a subnet m ask of a net work, he knows exact ly how m any host s need t o be scanned. Alt hough t he subnet m ask of a host usually can be det erm ined from looking at t he first oct et of t he I P num ber, t his request m ight discover t he net works t hat don't have a " nat ural" subnet m ask. That t ype of knowledge cannot be obt ained from looking at t he I P num ber alone. I n t his exam ple, t he scanned rout ers respond wit h subnet m asks of a hexadecim al ffffff00. This t ranslat es t o a decim al 255.255.255.0 subnet m ask of t he net work on which t hey reside. This m eans t hat t hese host s all belong t o a Class C net work. Querying for address m asks is anot her t ype of I CMP act ivit y t hat should be disallowed int o t he net work, for obvious reasons. Su m m a r y of M a ppin g Let 's briefly recap t he discussion about m apping. Mapping can be done using t he following m et hods: z

Sending individual I CMP echo request s t o host s in a net work

z

Sending I CMP echo request s t o t he broadcast addresses of a net work

z

Sending I CMP echo request s t o net work and broadcast addresses of subdivided net works

z

Sending an I CMP address m ask request t o a host on t he net work t o det erm ine t he subnet m ask t o bet t er underst and how t o m ap efficient ly

N or m a l I CM P Act ivit y This sect ion exam ines som e of t he expect ed uses of I CMP—specifically, several different error m essages t hat I CMP sends t o inform a host of som e kind of problem sit uat ion. Looking at m ut ant I CMP act ivit y is m ore int riguing, but you've got t o be able t o underst and what 's norm al before you can recognize abnorm al I CMP act ivit y. H ost Unr e a ch a ble I n t he following I CMP out put , you can see an error m essage t o sending.host, which is at t em pt ing t o send t raffic t o a t arget host :

router > sending.host: icmp: host target.host unreachable

For som e reason, t he target.host is unreachable—perhaps no host resides at t he request ed I P address, perhaps t he host is t em porarily unavailable, or perhaps t he host is suffering from som e kind of m isconfigurat ion t hat prevent s it from responding. I n a sit uat ion such as t his, t he host obviously cannot send an error m essage, so t he rout er t hat oversees t he t arget host 's net work int ervenes t o deliver t he m essage. I n t his case, t he rout er inform s t he sending host t hat t he t arget host is unreachable. As you can probably guess, t his gives a scanner valuable inform at ion t hat he can use t o help him m ap t he net work. I f a scanner is collect ing inform at ion about live host s in a net work t o lat er scan, t hose t hat have been ident ified as unreachable would likely not be scanned again. This m akes any subsequent scans m ore focused. The valuable reconnaissance inform at ion t hat can be gleaned from m any of t he I CMP unreachable com m ands can be det rim ent al t o t he securit y of a given net work. Cisco rout er access cont rol list s have a st at em ent no ip unreachables t hat can silence t he rout er int erface from issuing t he I CMP unreachable m essages. Por t Unr e a cha ble The I CMP out put t hat follows dem onst rat es how a t arget host inform s a sending host t hat a request ed UDP port is not list ening. I n t his exam ple, t he sending host at t em pt s t o send t raffic t o t he t arget host on t he UDP net work t im e prot ocol ( nt p) port :

target.host > sending.host: icmp: target.host udp port ntp unreachable (DF)

Therefore, t he prot ocol used t o deliver t he error m essage is I CMP. Rem em ber t hat when you exam ined TCP, t hat prot ocol had a different way of inform ing a sending host t hat a port was not act ive. I t ret urned a packet wit h t he TCP RESET flag set t o indicat e t hat t he port was not list ening. UDP has no built - in m echanism t o report about t his error, so it enlist s I CMP t o assist . Again, you can see t hat valuable reconnaissance can be gained from t his I CMP error m essage—nam ely t hat scanned UDP port s t hat do not respond wit h t his m essage could be list ening port s. But , it is also possible t hat scanned UDP port s t hat do not respond m ight never have received t hat scan due t o packet loss. I t is also possible t hat out bound port unreachable m essages are blocked from leaving t he net work. So, you can see t hat t he absence of a port unreachable m essage from a scanned UDP port is not a definit ive confirm at ion t hat t he port is list ening. Adm in Pr oh ibit e d Take a look at anot her possible problem sit uat ion wit h t he following out put :

router > sending.host: icmp: host target.host unreachable - admin prohibited

I n t his scenario, a sending host is at t em pt ing t o deliver t raffic t o a t arget host . A rout er is at t he gat eway of t he t arget host net work. The rout er has an access cont rol list t hat prohibit s cert ain t ypes of t raffic from ent ering t he net work. This could be a port t hat is blocked, a prot ocol t hat is blocked, or possibly t he source I P or subnet t hat is denied access, or t he dest inat ion I P or subnet t hat is prot ect ed. A rout er m ight respond t o t his condit ion wit h an I CMP " unreachable - adm in prohibit ed" m essage. Alt hough t his I CMP m essage does not indicat e what is being blocked ( a dest inat ion port , a source I P, or an I P prot ocol, for inst ance) , an ast ut e scanner can at t em pt different com binat ions of connect ions and figure out what is being disallowed int o t he net work and possibly find ot her avenues int o t he net work t hat are not blocked. N e e d t o Fr a g Anot her I CMP m essage warns t hat a desired host is unreachable because of a problem wit h fragm ent ing a dat agram :

router > sending.host.net: icmp: target.host unreachable - need to frag (mtu 1500)

The DF out put in TCPdum p m eans t hat t he Don't Fragm ent flag is set . As t he nam e im plies, if t his flag is set , fragm ent at ion will not be done on t he dat agram . I f t his flag is set and t he dat agram crosses a net work in which fragm ent at ion is required, t he rout er discovers t his, discards t he dat agram , and sends an I CMP error m essage back t o t he sending host . The I CMP error m essage cont ains t he m axim um t ransm ission unit ( MTU) of t he net work t hat required fragm ent at ion. Som e host s conversing in TCP int ent ionally send an init ial dat agram across t he net work wit h t he DF flag set as a way t o discover t he sm allest MTU for a part icular source- t o- dest inat ion pat h. I f t he I CMP error m essage is ret urned wit h t he sm allest MTU, t he host t hen packages all dat agram s bound for t hat dest inat ion in sm all enough chunks t o avoid fragm ent at ion. The int ent is t o elim inat e t he overhead and inefficiencies in packet loss associat ed wit h fragm ent at ion. Tim e Ex ce e de d I n - Tr a n sit This I CMP m essage inform s a sending host t hat a dat agram has overst ayed it s welcom e on t he I nt ernet :

routerx > sending host: icmp: time exceeded in-transit

I P needs a way t o flush a lost dat agram from t he I nt ernet , perhaps one t hat is in som e kind of rout ing loop in which it is bouncing aim lessly bet ween rout ers. The m eans used t o prevent wayward dat agram act ivit y involves a field in t he I P header known as t he t im e- t o- live ( TTL) value. Different operat ing syst em s set different init ial TTL values. To exam ine default init ial TTL values set by operat ing syst em s, go t o ht t p: / / proj ect .honeynet .org/ papers/ finger/ t races.t xt . When a dat agram t raverses a rout er on it s t ravel from t he source t o dest inat ion, each rout er decrem ent s t he TTL value by 1. I f t he value ever becom es 0, t he rout er discards t he dat agram and sends an I CMP " t im e exceeded in- t ransit " m essage back t o t he sending host . Chapt er 5, " St im ulus and Response," shows how t racerout e uses t his I CMP " t im e exceeded in- t ransit " m essage along wit h increm ent ing TTL values t o discover and record int erim rout ers along t he pat h from a given source t o dest inat ion. Em be dde d I nfor m a t ion in I CM P Er r or M e ssa ge s I t is helpful t o underst and t hat when an I CMP error m essage is ret urned, t here is som e addit ional inform at ion t hat is supplied in t he dat agram . Specifically, aft er t he act ual I CMP m essage, you will find t he I P header followed by eight byt es of prot ocol header and dat a of t he original dat agram t hat caused t he error, as seen

in Figure 4.2. This inform at ion allows t he receiving host t o associat e t his error wit h t he sending process and react appropriat ely. An ext ernal response t o an I CMP error m essage is not expect ed because RFC 1122 describes t his as one of t he condit ions for which no I CMP reply should be generat ed. Figu r e 4 .2 . I CM P e r r or m e ssa ge for m a t .

I t is also useful t o be aware t hat not all TCP/ I P st acks will precisely copy t he I P header and following eight byt es. I t would seem logical t hat t he em bedded inform at ion following t he I CMP error m essage, reflect ing t he first 28 byt es of t he offending packet , would exact ly m at ch t he first 28 byt es of t he offending packet . I n fact , nm ap can be used t o discover a rem ot e host 's operat ing syst em by sending norm al and aberrant t raffic t o a t arget host . I t looks for responses and behavior of t he t arget host t hat will dist inguish it from st andard expect ed behavior t o assist in operat ing syst em classificat ion. One t est in a series of t raffic t o t he t arget host at t em pt s t o send a dat agram t o a closed UDP port . The desired response t o t his is an I CMP " port unreachable" m essage. But , nm ap exam ines several of t he fields in t he I CMP error m essage cont aining t he I P header and following eight byt es of t he init ial probe of t he UDP port . I t exam ines t hese fields t o see if t hey m at ch t he fields in t he dat agram t hat elicit ed t he error. This inform at ion is used t o det erm ine t he operat ing syst em . Su m m a r y of N or m a l I CM P I n t he previous sect ions, you exam ined som e of t he m any I CMP m essages t hat you m ight see while m onit oring your net work. You also saw m any of t he different inform at ive I CMP error m essages. As you not iced, t hese can be sent by eit her host s or rout ers t hat discover a problem . These sect ions also discussed t he not ion t hat som e of t he I CMP unreachable errors are best prevent ed from leaving your net work if you are concerned about t he reconnaissance inform at ion t hat could be gat hered from t hem .

M a liciou s I CM P Act ivit y Not unexpect edly, it was j ust a m at t er of t im e unt il I CMP becam e t aint ed in purpose. Today, I CMP has been corrupt ed for use in m any different t ypes of denial- of- service at t acks, and it has been used in a m ost st ealt hy at t ack as a covert channel. This sect ion exam ines som e of t hese m alicious uses of I CMP.

Bla ck I ce As I was driving t o work one wint ry m orning aft er a night of precipit at ion, it occurred t o m e t hat t he day's com m ut e was m uch like t he philosophy of m y j ob as a securit y analyst . I caut iously navigat ed t he long, winding, snow- covered driveway; slowed m y pace; shift ed t o a lower gear descending t he st eep hill out of t he neighborhood; and safely drove around t he abandoned car in m y lane going uphill. I t reat ed t he ident ified hazards wit h due caut ion and respect , but it was t he unseen dangers such as black ice t hat worried m e. Each day, as I analyze t raffic t o our sit es, I have t his om nipresent uneasy feeling about what it is I am not seeing—t he black ice of our net works. I have seen first hand t he persist ence, guile, and cleverness t hat t he I nt ernet pirat es use t o t ry t o find and exploit what t hey want . As a securit y analyst , t his " What am I m issing?" sem i- paranoid at t it ude is one you m ust adopt . I f you becom e t oo com placent about t he securit y of your sit e, your sit e could spin out of cont rol from t he unident ified perils. Sm u r f At t a ck The infam ous Sm urf at t ack, shown in Figure 4.3, preys on I CMP's capabilit y t o send t raffic t o t he broadcast address. Many host s can list en and respond t o a single I CMP echo request sent t o a broadcast address. This capabilit y is used t o execut e a denial- of- service at t ack against a hapless t arget host or net work. Figu r e 4 .3 . An a t om y of a Sm u r f a t t a ck .

First , a m alicious host m ust craft an I CMP echo request wit h a spoofed source I P t o a broadcast address of an int erm ediat e net work. The spoofed source I P chosen

is t hat of t he vict im t arget host / net work. Next , t he int erm ediat e sit e m ust allow broadcast act ivit y int o t he net work. I f it does, t he I CMP echo request is sent t o all host s on t he given subnet t o which t he broadcast was sent . Finally, all t he live host s in t he int erm ediat e net work t hat respond send an I CMP echo reply t o what t hey believe t o be t he sender, or t he vict im host . The vict im host or net work on which it resides can becom e choked wit h all t he act ivit y and can suffer a degradat ion or denial- of- service at t ack if t he following condit ions exist : z

The m alicious user sends m any I CMP request s t o t he broadcast address.

z

The int erm ediat e sit e allows inbound broadcast t raffic.

z

z

The int erm ediat e sit e is large and has m any responding host s. On t he ot her hand, m any sm aller int erm ediat e sit es m ight be used t o achieve t he sam e result . The t arget sit e has a slow I nt ernet connect ion. To be m ore precise, t he I nt ernet connect ion m ust be suscept ible of being overwhelm ed by t oo m any packet s for t he support ed bandwidt h. Alt hough it is possible t o inundat e and clog any I nt ernet connect ion given enough t raffic, slower connect ions are m ore vulnerable.

Therefore, t his is anot her reason t hat you want t o deny broadcast t raffic from ent ering int o your net work. Your sit e cannot be used as a Sm urf am plificat ion net work if broadcast t raffic is not allowed. Tr ibe Flood N e t w or k The Tribe Flood Net work ( TFN) at t ack is anot her denial- of- service at t ack t hat uses I CMP for com m unicat ion. Figure 4.4 depict s t he at t ack. Unlike t he Sm urf at t ack, which originat es from one source and uses one int erm ediat e net work as an am plificat ion point , t he TFN at t ack enlist s t he help of m any dist ribut ed host s, known as daem on or zom bie host s. Hence, t he t erm dist ribut ed denial of service ( DDoS) is a m ore accurat e descript ion of t he use of dispersed host s t o part icipat e in an at t ack. Figu r e 4 .4 . Tr ibe Flood N e t w or k a t t a ck .

This at t ack requires a TFN m ast er host and daem on host s t o be est ablished. These are t ypically com prom ised host s on which TFN was inst alled. The m ast er TFN host t hen inst ruct s t he daem on host s t o at t ack a vict im host , perhaps sim ult aneously. The com m unicat ion bet ween t he m ast er and daem on host is done using t he I CMP echo reply. The daem ons can send t he t arget host a UDP flood, a TCP SYN flood, an I CMP echo request flood, or a Sm urf at t ack. The m ast er inst ruct s t he daem on what t o do by sending com m ands in t he I CMP echo reply. The I CMP ident ificat ion num ber field in t he I CMP header of t he I CMP echo reply is used t o direct t he daem ons of t he act ion t o t ake. The dat a port ion of t he I CMP echo reply is used t o send argum ent s. You m ight be wondering why t his at t ack uses I CMP echo replies inst ead of I CMP echo request s. The reason is t hat m ore sit es block I CMP echo request s because t hey are aware of t he hazards of allowing t hem in t he net work. However, t hey m ay allow I CMP echo replies in t o get responses from pings t o host s out side t he net work and because t hey don't realize t he t hreat s posed by rogue I CMP echo request s. As you have probably concluded, by using several dist ribut ed int erm ediat e host s sim ult aneously t o flood t he t arget host , a denial- of- service at t ack against t he t arget net work or t arget host is t he ant icipat ed out com e. I f you want t o read m ore about TFN, go t o ht t p: / / www.cert .org/ and search for incident I N- 99- 07.

Se lf- I n flict e d D e n ia l of Se r vice ? I t was Decem ber 29, 1999. As I prepared t o begin m y st int at a Y2K cent er for t he Office of t he Secret ary of Defense, I m ulled over t he rum ors of im pending cyberspace doom . The widespread consensus was t hat t here would be m assive denial- of- service at t acks direct ed against infrast ruct ure services such as power and t ransport at ion. Despit e t he

hackers' prom ised plans of drunken celebrat ion wit h t he m asses, t he prevailing sent im ent was t hat t he release of dist ribut ed denial- of- service t ools such as TFN coincided wit h t he arrival of t he new m illennium . I n response t o t he perceived t hreat , m any sit es all but shut down or great ly rest rict ed access t o t heir net works. The irony of t his was not ed by a coworker who said, " I t seem s rat her funny t o avoid a denial- of- service at t ack by t urning off t he services yourself." W in Fr e e ze The WinFreeze at t ack essent ially causes a suscept ible host t o at t ack it self—an ugly kind of self- m ut ilat ion:

router router router router router router router router router

> > > > > > > > >

victim.com: victim.com: victim.com: victim.com: victim.com: victim.com: victim.com: victim.com: victim.com:

icmp: icmp: icmp: icmp: icmp: icmp: icmp: icmp: icmp:

redirect redirect redirect redirect redirect redirect redirect redirect redirect

243.148.16.61 to host victim.com 110.161.152.156 to host victim.com 245.211.87.115 to host victim.com 49.130.233.15 to host victim.com 149.161.236.104 to host victim.com 48.35.126.189 to host victim.com 207.172.122.197 to host victim.com 113.27.175.38 to host victim.com 114.102.175.168 to host victim.com

The I CMP redirect m essage inform s a sending host t hat it has t ried t o use a nonopt im al rout er and t ells t he sending host t o add a m ore opt im al rout er t o it s rout ing t able. The WinFreeze at t ack can cause a vulnerable Windows NT host t o suffer a denial of service by flooding it wit h I CMP redirect m essages. This is execut ed on a net work on which t he vict im host resides and purport s t o send I CMP redirect m essages from t he rout er. When t he Windows host receives a flood of t hese m essages, it at t em pt s t o add t hese changes t o it s own rout ing t able and could suffer from degraded perform ance. I n t he preceding out put , t he rout er is inform ing vict im .com t o redirect it s t raffic t o m any different random I P num bers t o it self. The host vict im .com m ight be overwhelm ed when t rying t o apply all t hose changes t o it s own rout ing t able. Lok i Probably t he m ost subversive and dest ruct ive use of I CMP t o dat e is known as Loki. I n Norse m yt hology, Loki was t he god of t rickery and m ischief. So t oo is t he Loki exploit t he m ast er of t rickery. As you have seen, I CMP is int ended t o be used t o inform of error condit ions and t o m ake sim ple request s. As such, int rusion analyst s prior t o t he release of Loki regarded I CMP as a fairly harm less prot ocol, except for t he denial- of- service at t acks generat ed using it and for t he net work m apping inform at ion it could provide if not blocked.

Loki uses I CMP as a t unneling prot ocol for a covert channel. A covert channel is one t hat uses a t ransport m et hod or dat a field in a secret or unexpect ed m anner. I n ot her words, t he t ransport vehicle is I CMP; but operat ionally, Loki act s m uch like a client / server applicat ion. I f a host is com prom ised and a Loki server is inst alled, it can respond t o t raffic sent t o it by a Loki client . For inst ance, t he Loki client could send a request t o t he Loki server t o cat / et c/ passwd t o display t he password file. The Loki client user t hen would see t he out put from t he display, capt ure it , and possibly crack t he password file. You can find m ore inform at ion on Loki at ht t p: / / www.phrack.com / issue 49, art icle 6. The danger in t his whole schem e is t hat a seem ingly innocuous prot ocol is being used t o do som e very sophist icat ed and pot ent ially dam aging exchanges. Again, I CMP was never int ended t o support applicat ions such as t his. My advice t o t he int rusion analyst is t o regard I CMP t raffic wit h height ened suspicion and t o st op j ust shy of out right paranoia. Un solicit e d I CM P Ech o Re plie s Now, t ry your hand at som e analysis and put int o pract ice som e of t he t heory you j ust learned about I CMP exploit s by exam ining t he out put t hat follows:

reply.com reply.com reply.com reply.com reply.com reply.com

>192.168.127.41: >192.168.127.41: >192.168.127.41: >192.168.127.41: >192.168.127.41: >192.168.127.41:

icmp: icmp: icmp: icmp: icmp: icmp:

echo echo echo echo echo echo

reply reply reply reply reply reply

What you observe here is a host , reply.com , sending t he 192.168.127.41 host I CMP echo reply t raffic. This would not be unusual if t he 192.168.127.41 host had sent an I CMP echo request elicit ing t hese responses. However, t his is not t he case; no out bound I CMP echo request s were sent from 192.168.127.41. Why m ight som eone init iat e such act ivit y? You learn possible reasons in t he next t hree sect ions. One t hing t o keep in m ind is t hat for t his kind of act ivit y t o be det ect ed, you m ust have som e kind of I DS or support ing soft ware capable of m aint aining st at e. This m eans t hat you m ust be able t o det erm ine whet her any prior t raffic had issued I CMP echo request s. Many I DSs do not m aint ain st at e inform at ion and cannot det ect such anom alous act ivit y. Let 's exam ine som e of t he possible t heories t hat m ight explain t his anom alous act ivit y. Th e or y 1 : Spoofin g

The first t heory poses t he possibilit y t hat you see t his t raffic because som eone has borrowed t he source I P 192.168.127.41 and has issued I CMP echo request s t o

reply.com using t he spoofed source I P; reply.com t hen replies t o t he real 192.168.127.41 I P address. I f you saw I CMP echo replies from m any ot her host s on t he sam e net work as reply.com , you could be a Sm urf t arget . A dram at ic increase in spoofing act ivit y has arisen, so t his is t he m ost com m on explanat ion for t his t ype of act ivit y. Typically, when you have wit nessed unsolicit ed I CMP echo replies t hat appear t o be using your spoofed source I Ps ( in t his exam ple, 192.168.127.41) , you m ight see ot her unsolicit ed act ivit y from t he sam e int erm ediat e host ( in t his exam ple, reply.com ) . You usually don't see t his act ivit y in isolat ion—you m ight see t hese replies going t o m any different 192.168.127 host s, not j ust a single reply m ult iple t im es. Th e or y 2 : TFN

A second t heory involves t he TFN at t ack. You learned t hat t he TFN m ast er com m unicat es wit h it s TFN daem ons using I CMP echo replies. Therefore, anot her possibilit y is t hat t he host receiving t he unsolicit ed I CMP echo replies, 192.168.127.41, has becom e a vict im TFN daem on. Alt hough t he I CMP ident ificat ion value field is used t o direct t he daem on host t o at t ack t he vict im , t he exact value found in t his field m ight not be predict able if t he at t acker changes t he default source code. The m ore obvious way t o det erm ine whet her t he 192.168.127.41 has becom e an unwit t ing TFN daem on is t o exam ine t he out bound act ivit y from 192.168.127.41 aft er receiving t he I CMP echo request s. I f it sends a flood of unexplained t raffic out bound, it is possibly part icipat ing in a TFN at t ack. Th e or y 3 : Lok i

The final t heory is t hat t his could be an exchange bet ween a Loki client and a Loki server. When Loki t raffic is exchanged, it m ight not have a pat t ern of each I CMP echo request generat ing a reply. I t is possible for t he Loki server t o respond wit h m ult iple I CMP echo replies t o a single I CMP echo request . Original releases of Loki had a signat ure of a st at ic value in t he sixt h and sevent h byt es ( st art ing wit h byt e 0) of t he I CMP m essage. This could be det erm ined by dum ping t he t raffic using TCPdum p wit h hexadecim al out put and observing t he lack of change in t his field t hat is t he I CMP sequence num ber. This field is usually unique for each I CMP echo request sent out and, m uch like t he I P header ident ificat ion num ber, incr em ent s by 1 or 256 for each subsequent I CMP echo request . Lat er incarnat ions of Loki m ight use encrypt ion and m ight not be decipherable in t his m anner. As you have wit nessed, I CMP echo t raffic, whet her request or reply, can facilit at e som e noxious act ivit y. So, t his is an excellent candidat e for blocking by a packet filt ering device. Su m m a r y of M a liciou s I CM P Tr a ffic

To wrap up t his sect ion, you learned t hat I CMP has been m anipulat ed in use for ot her purposes t han t he int ended ones. I CMP can be used in a denial- of- service at t ack, as you observed in t he Sm urf and WinFreeze at t acks. I CMP was used m ore as a conduit for com m unicat ion in t he TFN at t ack. I t m ight not be used direct ly as a denial- of- service at t ack, but it enables a denial- of- service at t ack t o occur by providing t he com m unicat ion vehicle bet ween t he TFN m ast er and daem ons. Finally, you saw t hat Loki has com plet ely alt ered t he original purpose of I CMP by using it as a t unneling m echanism for m alicious act ivit y.

To Block or N ot t o Block Aft er reading about all t he havoc t hat I CMP now can wreak, it appears t hat I CMP left Kansas along wit h Dorot hy and Tot o. From a reconnaissance aspect , if you can elicit any of t he following I CMP m essages from a host , you know you have reached a live host : z

" prot ocol unreachable"

z

" port unreachable"

z

" I P reassem bly t im e exceeded"

z

" param et er problem "

z

" echo reply"

z

" t im est am p reply"

z

" address m ask reply"

Also, if you can get a rout er t o report I CMP host unreachable errors, it is possible t o inversely m ap a net work assum ing t hat t hose host s which do not have t his error report ed are indeed live host s. As if t his isn't enough inform at ion, t he following com m on I CMP m essages are sent by rout ers only so if you can elicit any of t he following, you can ident ify a sit e's rout ers: z

" fragm ent at ion needed but don't - fragm ent bit set "

z

" adm in prohibit ed"

z

" t im e exceeded in t ransit "

z

" net work unreachable"

z

" host unreachable"

And, finally, we can discover m ore reconnaissance by t he following I CMP m essages: z

z

z

z

z

z

" adm in prohibit ed: can assist in exam ining what t ype of t raffic t he sit e blocks" " address m ask reply: gives t he subnet m ask of t he net work on which t he responding host resides" " t im e exceeded in t ransit : used in t racerout e t o discover rout ers and net work t opology" " prot ocol unreachable: can be used t o inversely m ap a host 's list ening prot ocols" " port unreachable: can be used t o inversely m ap a live host 's list ening UDP port s" " fragm ent at ion needed but don't fragm ent bit set : can be used t o det erm ine t he MTU of links for use in at t acks t hat use fragm ent s"

Given all t he reconnaissance t hat I CMP can supply, why not j ust uncondit ionally block all incom ing and out going I CMP t raffic? Som e sit es do j ust t his, but let 's exam ine som e of t he repercussions of blocking all inbound I CMP. Un r e qu it e d I CM P Ech o Re qu e st s Obviously, your abilit y t o do diagnost ic act ivit y using ping is broken when you block bot h inbound I CMP echo request s and echo replies. The good news is t hat I CMP echo request s and replies cannot be used as a front for st olen goods if blocked. The inconvenience suffered by t his loss m ight be j ust ified by t he im provem ent of your securit y post ure, elim inat ing a possible st ealt hy avenue int o your net work. You m ight face a t em pt at ion t o block only inbound I CMP echo request s, which would enable you t o do diagnost ics from your net work and receive a response by virt ue of t he I CMP echo response gaining inbound access. The hackers know t his, however, and as you have wit nessed wit h Tribe Flood Net work and Loki, t hey are relying m ore on t he use of I CMP echo reply as a delivery m echanism . Kiss t r a ce r ou t e Goodbye Whet her you use t he UNI X t racerout e com m and or t he Windows t racert com m and t o discover t he rout ers t hrough which a dat agram t ravels on it s pat h from source t o dest inat ion, blocking inbound I CMP prevent s you from execut ing t hese com m ands from your net work t o ot her net works. These com m ands require inbound I CMP " t im e exceeded in- t ransit " m essages t o operat e correct ly. By

prevent ing all I CMP int o t he net work, you break your use of t racerout e out bound. The Windows t racert com m and uses t he I CMP echo request , so blocking inbound I CMP precludes a user from doing a t racert t o a m achine in your net work. The UNI X t racerout e uses UDP as t he prot ocol, however, so blocking inbound I CMP does not prevent som eone from execut ing a UNI X t racerout e t o a host in your net work. Sile n ce of t h e LAN s As you learned in t his chapt er, I CMP can inform about unreachable condit ions t o a part icular host or port . When you block all inbound I CMP m essages, host s or rout ers on your net work cannot receive t hese inform at ive m essages. This does not produce cat ast rophic result s, but it does cause som e inefficiencies. As an exam ple, a host on your net work m ight at t em pt a TCP connect ion t o anot her host t hat m ight be down. This could elicit a "host unreachable" m essage from a rem ot e rout er, but t he host at t em pt ing t his connect ion doesn't receive t he I CMP unreachable m essage because it is blocked. The sending host ret ries unt il it t im es out , t hereby sending unnecessary t raffic. Br ok e n Pa t h M TU D iscove r y As discussed previously, when possible, a host sending TCP t raffic t ries t o avoid fragm ent at ion of dat agram s. This is done using pat h MTU discovery. As covered in t his chapt er, a sending host uses t he Don't Fragm ent flag in a discovery packet . The int ent is for t he discovery packet t o reach t he dest inat ion host wit hout being fragm ent ed, or for t he sending host t o receive an I CMP " need t o frag" m essage wit h t he value of t he sm aller MTU found in t he m essage. Therefore, blocking all inbound I CMP breaks t his m echanism and causes som e significant problem s. A host sending t he discovery packet expect s t o receive an I CMP " need t o frag" m essage if fragm ent at ion is required. Because it receives no such m essage due t o t he inbound I CMP block, it cont inues t o send oversized dat agram s wit h t he Don't Fragm ent flag set . These are dropped, but t he sending host is never inform ed of t his. Packet s sent t hat are sm aller t han t he sm allest MTU along t he pat h arrive at t he dest inat ion, but larger ones do not . So, if you choose t o block I CMP, m ake sure t hat you m ake an exclusion t o allow " host unreachable - need t o frag" I CMP m essages int o your net work.

Su m m a r y I CMP is a prot ocol t hat is supposed t o be used t o alert host s of problem condit ions or t o exchange sim ple m essages. I t can be t ransm it t ed bet ween t wo host s exclusively, or it can be t ransm it t ed t o m ult iple host s using t he broadcast address.

Regard I CMP as a pot ent ial t hreat . This chapt er has ident ified som e of t he current known m alicious uses of I CMP. No doubt , m any m ore will com e, wit h m any new flavors of unknown subversions. Block inbound I CMP, but do so wisely and select ively. Alt hough you will prevent pot ent ially m alicious t raffic from ent ering your net w ork, m ake sure t hat you underst and t he adverse consequences t o your own net work of blocking inbound I CMP t raffic.

Ch a pt e r 5 . St im u lu s a n d Re spon se

Up unt il t his chapt er, you have been exposed t o m ost ly st im ulus act ivit y. Not m uch t im e or discussion has been invest ed present ing t he unique responses from different st im uli. This served you well when new t heories and concept s were int roduced so as not t o add layers of com plexit y t o new m at erial. Hopefully, now t hat you underst and t he basic t heory, you are ready t o diversify your exposure. Most current net work int rusion det ect ion syst em s have very high rat es of false posit ives. I n ot her words, t hey cannot yet m ake wise decisions on whet her t raffic com ing across a given net work is harm ful or innocuous. So, t he net work int rusiondet ect ion syst em ( NI DS) oft en errs on t he side of caut ion, and alarm s when t here is no problem . There are m any reasons for t his, but t he short explanat ion is t hat m ost t im es t he signat ures or rule set t hat t he NI DS uses t o det erm ine suspicious t raffic are t oo generic. I f t hese signat ures cannot be or are not m ore precisely cust om ized, t he NI DS will oft en alert when no problem exist s. Therefore, t he analyst m ust m ake t he dist inct ion bet ween false posit ive and valid alarm s. You exam ine t he t raffic associat ed wit h t he alarm and det erm ine whet her it is a false alarm . To m ake such a det erm inat ion, you need t o have a foundat ion in what seem ingly norm al or abnorm al t raffic looks like. Com m on sense dict at es t hat all aspect s of st andard st im uli and responses cannot be covered in t his chapt er. The int ent ion is t o im part som e general knowledge, however, so t hat you can m ake a m ore int elligent det erm inat ion of t he kind of t raffic you observe on different net works. This chapt er first exposes you t o t he expect ed behavior of t ypical applicat ions and prot ocols. Next , you learn about a cat egory of act ivit y t hat m anifest s expect ed, yet uncom m on behavior. Finally, you descend from t he sublim e t o t he ridiculously abnorm al act ivit y. This is m uch like t he evolut ion of a budding court ship. Bot h part ners are on t heir

best behavior at first because good m anners are expect ed. The com fort zone seeps in aft er awhile, and t he expect ed fine et iquet t e det eriorat es from furled pinkies while drinking t ea t o random slurps. Fam iliarit y cert ainly breeds bad m anners as t im e passes and t he first hardy belch rum bles.

Th e Pe r son a l H a za r ds of W or k in g w it h Fa lse Posit ive s Several m ont hs ago, I was driving t o work when I saw a sim ult aneous red flash of bot h t he bat t ery and brake indicat or light s appear on t he dashboard of m y car. They disappeared im m ediat ely, but it concerned m e. This happened several m ore t im es on t he rem ainder of t he com m ut e. I am t he first t o adm it t hat I am a m echanical m oron and should never quest ion anyt hing m y car professes t o t ell m e because it is far sm art er t han I am about it s healt h. Yet , it seem ed st range t o m e t hat t hese seem ingly unrelat ed light s flashed t oget her. Aft er all, unless I had bat t ery- powered brakes ( and I was alm ost cert ain I didn't ) , t here was no logical correlat ion in m y m echanically challenged m ind of t he t wo different light s. I t ried t o explain it away as a false posit ive convincing m yself t hat perhaps a loose wire of som e sort was t he culprit inst ead of real m echanical problem s. Som e t im e passed and t he problem got worse, so I gave in and called t he service shop. I t old t he service m anager about t he problem and her response t old m e she was doing her very best not t o yell, " You m oron! " int o t he phone. Despit e her t raining in cust om er relat ions, she could barely cont ain her rage at m y st upidit y. She t old m e t hat it was m y car's alt ernat or and I could be st randed— or som e ot her cat ast rophic t hings could happen like t he car could blow up, or I could put an eye out , yadayadayada. Needless t o say aft er hearing t he " sky- is- falling" prognosis of m y car and m y life, I brought t he car in t o be repaired right away, and t he problem went away. I got t o t hinking about t he incident and began t o reflect t hat I had been a relat ively conservat ive and caut ious person m ost of m y life who, years ago, would have t aken t he car int o t he shop at t he first sign of t rouble. What had changed in all t hese years? My only guess is t hat I 'm so used t o looking at NI DS out put s of false posit ives t hat I t ry t o explain everyt hing away in t hat sam e light . I n ot her words, I believe not hing any m ore because everyone and everyt hing is a liar!

Th e Ex pe ct e d What t he heck is norm al t raffic anyway? I t would be an exercise in fut ilit y— and

undoubt ed head- bobbing boredom —t o t ry t o dem onst rat e all aspect s of norm al behavior. To m ake t his a m ore m anageable and int erest ing t ask, t his sect ion reviews sit uat ions and t raffic pat t erns t hat are likely t o be t he bulk of what you will see on your net work. Specifically, t he response behaviors of host s and rout ers are exam ined when different t raffic is sent and received under different condit ions wit h different prot ocols. A very hard challenge in developing t his m at erial was t rying t o elucidat e what is " norm al." Because expect ed behavior ent ails so m any facet s and dim ensions, it is im possible t o discuss t hem all here. I ronically, norm al m ight best be described as not abnorm al. For t his reason, t his book discusses m any exam ples of deviant behavior. Re qu e st for Com m e n t s I s t here som e kind of st andard baseline for what is expect ed? Request for Com m ent s ( RFCs) cont ain t he foundat ion docum ent at ion for t he I nt ernet . They elaborat e t he expect ed st andards for individual prot ocols. The I nt ernet is best viewed as a series of different prot ocols, each docum ent ed by one or m ore RFCs. RFCs do not change aft er t hey are issued; prot ocol enhancem ent s are docum ent ed by issuing new RFCs. Som e of t he m ost pert inent RFCs for t his sect ion include t he following: z

z

z

z

RFC 793. This RFC discusses t he Transm ission Cont rol Prot ocol ( TCP) , describing t he funct ions t o be perform ed by TCP, t he program t hat im plem ent s it , and it s int erface t o program s or users requiring it s services. RFC 768. This RFC discusses t he funct ioning of t he User Dat agram Prot ocol ( UDP) , which is an unreliable connect ionless prot ocol. RFC 791. This RFC discusses t he I nt ernet Prot ocol ( I P) , t he prot ocol t hat provides for t ransm it t ing blocks of dat a called dat agram s from sources t o dest inat ions. RFC 792. This RFC discusses t he I nt ernet Cont rol Message Prot ocol ( I CMP) , t he prot ocol t hat deals wit h er rors in dat agram processing.

You can find m ore inform at ion about RFCs at ht t p: / / www.rfc- edit or.org/ . TCP St im u lu s- Re spon se This sect ion exam ines responses t o an at t em pt ed t elnet connect ion m ade under various condit ions such as a host t hat doesn't list en on t he t elnet port or a rout er blocking t he connect ion. Telnet is used as a represent at ive TCP applicat ion. You will see som e of t he varied responses t o t he ident ical st im ulus. Obviously, t his is not an exhaust ive list of all condit ions t hat m ight be encount ered wit h an at t em pt ed t elnet connect ion. The part icular set of condit ions has been select ed for

illust rat ion because it represent s som e of t he m ost com m on. D e st in a t ion H ost List e n s on Re qu e st e d Por t

A host , t el_client .com , at t em pt s t o t elnet t o m yhost .com , which list ens on port t elnet ( TCP port 23) . St im ulus:

tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 (DF)

m yhost .com offers t elnet and connect ion is perm it t ed. Response:

myhost.com.telnet > tel_client.com.38060: S 2009600000:2009600000(0) ack 3774957991 win 1024

The previous TCPdum p out put exam ines t he expect ed response when client host t el_client .com at t em pt s t o connect t o t he t elnet port on dest inat ion host m yhost .com . You have already been exposed t o t he concept of t he t hree- way handshake for TCP session est ablishm ent . I f you rem em ber, t he first part of t he process is for t he client t o init iat e a TCP connect ion wit h t he SYN flag set t o t he server t o signal t he desire t o connect . t el_client .com issues such a SYN connect ion request t o m yhost .com t o connect t o t he t elnet port . Now, if m yhost .com offers t elnet , access is perm it t ed, and no ot her im pedim ent s arise; you see t he expect ed response of m yhost .com replying t o t he request wit h a SYN/ ACK. This says t hat m yhost .com is list ening at t he t elnet port and can est ablish t his t elnet connect ion. The final part of t he t hree- way handshake not shown would be t el_client .com responding t o m yhost .com wit h a TCP connect ion wit h only t he ACK flag set . D e st in a t ion H ost N ot List e nin g on Re qu e st e d Por t

Look at t he following TCPdum p out put t o see t he response from t he sam e at t em pt ed t elnet connect ion. This t im e, t he scenario changes and m yhost .com does not list en for t elnet connect ions. The expect ed response is a RESET/ ACK t hat is an abrupt t erm inat ion t o t he connect ion. St im ulus:

tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 (DF)

m yhost .com does not offer t elnet . Response:

myhost.com.telnet > tel_client.com.38060: R 0:0(0) ack 3774957991 win 0

I n t he response, you see t hat t he ACK num ber 3774957991 from m yhost .com is one m ore t han t he t el_client .com 's SYN of 3774957990. This m eans t hat m yhost .com received t he t elnet at t em pt , and t his would be t he expect ed sequence num ber of t he next dat a byt e.Yet , t he R in t he response indicat es a connect ion RESET or t erm inat ion because m yhost .com does not list en on port t elnet . Aft er t he RESET/ ACK is issued by m yhost .com , t here should be no reply from t el_client .com . D e st in a t ion H ost D oe sn 't Ex ist

What happens if t el_client .com at t em pt s a t elnet connect ion t o m yhost .com , but m yhost .com doesn't exist ? Looking at t he following TCPdum p out put , you see an exam ple of such an exchange. Oft en a rout er responds t o a sit uat ion such as t his in which a host cannot respond. I n t his case, rout er.com , t he default rout er for t he subnet on which m yhost .com was form erly found, inform s t el_client .com using I CMP t hat m yhost .com is unreachable. St im ulus:

tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 (DF)

m yhost .com doesn't exist . Response:

router.com > tel_client.com: icmp: host myhost.com unreachable

This im plies t hat m yhost .com is a host wit h a regist ered dom ain nam e syst em ( DNS) I P address, but t he I P num ber is no longer act ive or t he host is current ly down or suffering from som e kind of m isconfigurat ion prevent ing it from responding. The response from rout er.com inform s of t his unreachable error condit ion using I CMP as t he prot ocol t o deliver t he m essage t o t el_client .com .

D e st in a t ion Por t Block e d

The next TCPdum p out put shows anot her possible condit ion. What if a filt ering rout er blocks t he t elnet port ? What kind of response will you see? Again, t he rout er for m yhost .com , rout er.com , inform s t el_client .com t hat m yhost .com is unreachable and qualifies t hat t his is because of an admin prohibited filter, m eaning t hat t he access was blocked. rout er.com was j ust t rying t o be helpful and inform at ive in t his and t he previous sit uat ions exam ined, but it is giving out som e valuable reconnaissance inform at ion if som eone is probing your net work. I t is possible t o silence Cisco rout ers by put t ing a no ip unreachables st at em ent in t he access cont rol list of t he appropriat e int erface as you learned in Chapt er 4, " I CMP." This prevent s t he rout er from being as verbose and lim it s t he inform at ion t hat it divulges. St im ulus:

tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 (DF)

Rout er responds t o blocked t elnet request . Response:

router.com > tel_client.com: icmp: myhost.com unreachable - admin prohibited filter D e st in a t ion Por t Block e d, Rou t e r D oe sn 't Re spon d

This TCPdum p out put illust rat es what happens when a rout er blocks t raffic, but t he rout er has been m uzzled from issuing unreachable m essages. Because no I CMP error m essage inform s t el_client .com t hat som et hing is am iss, it st ubbornly cont inues t o send ret ries t o connect . The num ber of ret ries and t he t im e int ervals in which t hey are sent are based on t he TCP/ I P st ack of t he operat ing syst em of t he host sending t he ret ries. Finally, t he host t el_client .com gives up on t he connect ion aft er it has exhaust ed t he m axim um num ber of ret ries. St im ulus:

17:14:18.726864 tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 (DF)

Rout er does not respond t o blocked t elnet request .

Response:

17:14:21.781140 tel_client.com.38060 > 3774957990:3774957990(0) win 8760 3774957990:3774957990(0) win 8760 3774957990:3774957990(0) win 8760 (DF) myhost.com.telnet: S 1460> (DF) myhost.com.telnet: S 1460> (DF)

The t opic of ret ries or ret ransm issions will be exam ined in great er det ail in Chapt er 9, "Exam ining Em bedded Prot ocol Header Fields." UD P St im u lu s- Re spon se A DNS query is used in t his sect ion t o exam ine how UDP responds t o different st im uli. Specifically, a list ening dom ain port and a nonlist ening port are inspect ed. Because t he ot her st im uli exam ined in t he previous sect ion for TCP ( such as a host t hat doesn't exist or t he dom ain port blocked at t he rout er) elicit very sim ilar responses for t he UDP DNS query, t hey don't m erit repet it ion. D e st in a t ion H ost List e n in g on Re qu e st e d Por t

Looking at t he following exam ple, you see nslookup.com does a DNS query t o m yhost .com on a port dom ain from t he preceding TCPdum p out put . Chapt er 6, " DNS," explains t he TCPdum p DNS out put m ore t horoughly. You see a DNS ident ificat ion num ber, 51007, which is used t o pair up responses wit h request s. m yhost .com receives t he query and responds. m yhost .com com m unicat es on port dom ain ( 53) t o nslookup.com , responding t o DNS ident ificat ion num ber 51007. The 1/ 0/ 0 is TCPdum p DNS j argon for ret urning one answer resource record, no aut horit y records, and no ot her records. As wit h TCP, you see t hat t he UDP exchange was done using an ephem eral port , 45070, on t he client and t he wellknown dom ain server port . The response from m yhost .com uses t hese est ablished port s. St im ulus:

nslookup.com.45070 > myhost.com.domain: 51007+ (31) (DF)

m yhost .com runs t he dom ain service and responds. Response:

myhost.com.domain > nslookup.com.45070 51007 1/0/0 (193) (DF)

D e st in a t ion H ost N ot List e nin g on Re qu e st e d Por t

Observe t he following TCPdum p out put . I n t his case, m yhost .com responds wit h an I CMP m essage t hat UDP port dom ain is unreachable. Again, t his produces som e good reconnaissance about what services a t arget host does or does not offer. This t im e it is a loose- lipped host , not a rout er t hat offers m ore det ail t han necessary. St im ulus:

nslookup.com.45070 > myhost.com.domain: 51007+ (31) (DF)

m yhost .com doesn't run t he dom ain service and responds. Response:

myhost.com > nslookup.com: icmp:myhost.com udp port domain unreachable

I n Chapt er 9, you will learn t hat nm ap can scan for list ening UDP port s. I t at t em pt s t o do t his by assum ing t hat scanned t arget host UDP port s for which no I CMP " port unreachable" m essages are ret urned are list ening port s. This is som et im es referred t o as inverse m apping because t here is no direct indicat ion t hat t he port s are list ening. Unlike list ening TCP port s t hat respond at t he TCP prot ocol level wit h a SYN/ ACK, m ost UDP port s will not respond at t he UDP prot ocol level wit h a sim ple connect ion request . For inst ance, t he previous DNS query t o UDP port 53 received a response because it was com m unicat ing at t he levels above t he prot ocol level such as t he applicat ion level. I f you were t o exam ine t he em bedded payload, you would find a properly configured DNS query. The nm ap UDP port scanning sends 0 byt es of payload and t herefore cannot com m unicat e above t he prot ocol level. I CM P St im u lu s- Re spon se I CMP, as you have learned, differs from TCP and UDP. Nat urally, t he expect ed set of responses differs as well. This very brief sum m ary explains I CMP's uniqueness: z z

z

I CMP doesn't use prot ocol port s t o converse. I CMP can be a one- way t ransm ission t o inform of an error condit ion wit h no observed response. I CMP can be a request wit h an expect ed reply.

The error responses t hat m ight be encount ered using I CMP are t ypically

availabilit y issues, such as if t he host exist s or whet her access is allowed t o t he host . These are sim ilar t o t hose observed wit h t he TCP exam ples. Rat her t han rehash m ore of t he sam e, t he Windows t racert com m and is int roduced t o dem onst rat e norm al I CMP response used t o discover a rout e from a source t o dest inat ion host . W indow s t r a ce r t

The t racert com m and uses t he I CMP echo request and I CMP echo reply pair, also known as ping, t o discover t he rout ers t hrough which a dat agram passes on it s pat h from source t o dest inat ion host . The com m and out put looks like t his:

tracert target.my.com Tracing route to target.my.com [1.2.3.4] over a maximum of 30 hops: 1 129 ms 126 ms 130 ms router.my.com [1.2.3.1] 2 229 ms 124 ms 118 ms target.my.com [1.2.3.4] Trace complete.

When you execut e t he t racert com m and, you see t he int erm ediat e rout ers t hrough which t he I CMP echo request passes. This exam ple shows only one, rout er.m y.com , before reaching t he dest inat ion host t arget .m y.com . Each rout er and t he dest inat ion host receive t hree separat e I CMP echo request s, and t racert out put displays t he round- t rip t im e for each of t hose dat agram s t o reach t he rout er or dest inat ion host . For inst ance, t he first t hree I CMP echo request s sent t o rout er.m y.com t ook 129, 126, and 130 m illiseconds t o com plet e t he round- t rip wit h an I CMP echo response. The m ult iple it erat ions t o one rout er or host are done in case one or m ore I CMP echo request s or replies is dropped or lost because of net work problem s. Next , t arget .m y.com receives t hree I CMP echo request s and replies wit h t hree I CMP echo replies. TCPdu m p of t r a ce r t

This following TCPdum p out put is t he result of execut ing t he previous t racert com m and:

tracer.net > target.my.com: router.my.com > tracer.net: tracer.net > target.my.com: router.my.com > tracer.net: tracer.net > target.my.com: router.my.com > tracer.net: tracer.net > target.my.com: target.my.com > tracer.net: tracer.net > target.my.com: target.my.com > tracer.net:

icmp: icmp: icmp: icmp: icmp: icmp: icmp: icmp: icmp: icmp:

echo time echo time echo time echo echo echo echo

request [ttl 1] exceeded in-transit request [ttl 1] exceeded in-transit request [ttl 1] exceeded in-transit request reply (DF) request reply (DF)

tracer.net > target.my.com: icmp: echo request target.my.com > tracer.net: icmp: echo reply (DF)

t racert sends t he first I CMP echo request in an I P dat agram wit h a t im e- t o- live ( TTL) value of 1. The TTL is a value set by a sending host and decrem ent ed by each net work device t hrough which t he packet t raverses. TTL provides a m eans of discarding packet s t hat have overst ayed t heir welcom e on t he I nt ernet and m ight be bouncing aim lessly. I f a rout er decrem ent s t he TTL and t he value becom es 0, t he packet m ust be discarded and an I CMP " t im e exceeded in- t ransit " error m essage is ret urned. I n t he previous out put , aft er a TTL wit h a value of 1 is observed, t he rout er rout er.m y.com sends an I CMP " t im e- exceeded in- t ransit " m essage. This is because it decrem ent ed t he TTL and discovered a value of 0. I t m ust t hen discard t he packet and inform t he sending host . When used for t racert , however, t he original source host receiving t his I CMP error m essage records t he rout er from which it cam e. I f necessary, t racert t hen sends anot her I CMP echo request in an I P dat agram , but increm ent s t he TTL value by 1. This process repeat s unt il t he I CMP echo request finally m akes it s way t o t he dest inat ion host and receives an I CMP echo reply. By default , t hree different I CMP request s are sent t o each new hop for redundancy in case a packet is dropped. Not ice t hat t racer.net sends an I CMP echo request t o t arget .m y.com . I m m ediat ely, you see t he reply from rout er.m y.com com plaining via t he I CMP " t im e exceeded in- t ransit " m essage t hat t he TTL value has been decrem ent ed t o 0. This is seen for all t hree different I CMP echo request s. The host t racer.net t hen increm ent s t he TTL t o 2, which is enough t o allow it t o get t o t he act ual dest inat ion host , t arget .m y.com . The reason t hat you do not see TCPdum p display t he TTL value of 2 is because t he default behavior of TCPdum p is t o print t he TTL only when it has a value of 1 t o warn of an im pending problem . t arget .m y.com responds t o all t he I CMP echo request s wit h echo replies. I f you want t o exam ine t he TTL regardless of value using TCPdum p, use t he com m and line opt ion –vv.

Pr ot ocol Be n de r s Bet ween t he expect ed and abnorm al falls a net herland of applicat ions t hat exhibit norm al, yet unconvent ional, behavior. These applicat ions deviat e from t he expect ed behavior because t hey were designed different ly. These pat t erns are present ed so t hat if you encount er t hem , you will underst and t hat t his is norm al t raffic. Specifically, FTP and UNI X Tracerout e will be discussed. FTP is considered t o be a prot ocol bender because it defies t he convent ion of using one ephem eral and one

server port for t he durat ion of t he FTP connect ion. The UNI X Tracerout e is an unusual applicat ion because it com bines I CMP and UDP t o navigat e from source t o dest inat ion and record all rout ers on t he way. FTP The expect ed behavior of TCP t hat you have wit nessed so far is t o est ablish t he t wo port s used by t he client and server during t he t hree- way handshake. The client usually select s an ephem eral port great er t han 1023, and t he server list ens on a well- known port . Throughout t he rem ainder of t he est ablished TCP session, t he client and server t alk only on t hese est ablished port s. FTP differs from m ost ot her TCP services, because it com m unicat es using t wo different server port s. The first port is port 21, which is known as t he st andard FTP com m and port . The second port is used for dat a passed bet ween t he client and t he server. The act ual port used is different for act ive and passive FTP, as you will soon see. Act ive FTP Act ive FTP is so nam ed because t he FTP server opens up t he dat a connect ion t o t he client . Bot h act ive and passive FTP use port 21 t o issue FTP com m ands, such as t hose t o ret rieve or st ore a file. But , in act ive FTP, t he second is port 20 for FTP dat a passed bet ween t he client and t he server. The FTP dat a port is used t o exchange a file bet ween t he t wo host s or t o send a list ing of file direct ories from t he server t o t he client . Look at t he following TCPdum p out put for an act ive FTP session t o see an unusual, but norm al, change of TCP port s: Session negot iat ion:

ftp.client.com.35955 > ftp.server.com. 21: S 1884312222:1884312222(0) ftp.server.com.21 > ftp.client.com.35955: S 3113925437:3113925437(0) ack 1884312223 ftp.client.com.35955 > ftp.server.com.21: . ack 1 ftp.server.com.21 > ftp.client.com.35955: P 1:24(23) ack 1 ftp.client.com.35955 > ftp.server.com.21: . ack 24

dir com m and issued by t he user:

ftp.server.com.20 > ftp.client.com.35956: S 3558632705:3558632705(0) ftp.client.com.35956 > ftp.server.com.20: S 1901007864:1901007864(0) ack 3558632706 ftp.server.com.20 > ftp.client.com.35956: . ack 1

I n t he preceding exam ple, t he FTP connect ion is est ablished bet ween

ft p.client .com using ephem eral port 35955 and server port 21. The t hree- way handshake is com plet ed and som e dat a ( usually a welcom ing m essage) is passed bet ween t he t wo. This is sim ilar t o what you have wit nessed wit h ot her TCP prot ocols. Next , t he user issues t he FTP dir com m and from t he client request ing a list ing of t he direct ories on t he server. A new connect ion is est ablished from source port 20 of t he server t o t he ephem eral port 35956 on t he client . Alt hough you do not see it in t he out put , t he client inform ed t he server t hat it would be list ening on ephem eral port 35956 via t he FTP port com m and. Aft er t his new t hree- way handshake is com plet ed, ft p.server.com can send t he direct ories t o ft p.client .com on t his est ablished connect ion. Addit ional exchanges of dat a cause t he est ablishm ent of new connect ions and t he select ion of new ephem eral port s. This is called act ive FTP because t he FTP server init iat es t he dat a connect ion t o t he client . As you m ight guess, t his present s som e problem s for packet - filt ering devices t hat would have t o indiscrim inat ely allow t raffic int o t he net work com ing from source port 20. Passive FTP avoids t hese problem s by having t he int ernal FTP client m ake t he dat a connect ion. Pa ssive FTP

Passive FTP differs from act ive FTP in t he m anner in which t he dat a connect ion is est ablished. I t uses t he ident ical m et hod of connect ing t o FTP port 21 t o est ablish t he com m and port . But , as you observed wit h act ive FTP, t he problem arises when a packet - filt ering device m ust allow init ial SYNs in from source port 20 t o a highnum bered port inside t he packet - filt ering device. What is t o keep a hacker from using t his hole as a way int o t he net work? Aft er all, t he packet - filt ering device m ight not be exam ining t he cont ent of t he packet using t his hole and cannot be sure it is indeed FTP t raffic. Passive FTP avoids t his problem alt oget her by having t he client init iat e t he connect ion t o t he server. Rem em ber t hat act ive FTP required t hat t he server init iat e t he connect ion t o t he client . Look at t he following out put of a passive FTP session est ablishm ent : Session negot iat ion:

ftp.client.com.44890 > ftp.server2.com.21: S 4276284026:4276284026(0) win 8760 (DF) ftp.server2.com.21 > ftp.client.com.44890: S 1669630260:1669630260(0) ack 4276284027 win 8280 (DF) ftp.client.com.44890 > ftp.server2.com.21: . ack 1 win 9660 (DF)

dir com m and issued by t he user:

ftp.client.com.44891 > ftp.server2.com.3967: S 4282611109:4282611109(0) win 8760 (DF) ftp.server2.com.3967 > ftp.client.com.44891: S 1669768808:1669768808(0) ack 4282611110 win 8280 (DF) ftp.client.com.44891 > ftp.server2.com.3967: . ack 1 win 9660 (DF)

When ft p.client .com issues t he dir com m and on t he current com m and connect ion, it causes a dat a connect ion t o be est ablished. You don't see t his in t he TCPdum p out put , but ft p.server2.com inform s t he client via t he FTP port com m and t hat it will be list ening on port 3967. The client issues t he SYN connect ion t o t hat port and t he server responds wit h a SYN/ ACK. The direct ory list ing is done via t his connect ion. Because t he client is m aking an out bound connect ion t o t he server, t he subsequent responses from t he server can be allowed back in t he packet filt ering device wit h relat ively st rong confidence t hat t his is a " safe" connect ion. This involves less risk t han allowing act ive FTP connect ions by perm it t ing all inbound source port 20 t hrough t he packet - filt ering device. UN I X Tr a ce r ou t e The UNI X Tracerout e program discussed next shows a com binat ion of UDP and I CMP t o discover t he pat h t hat a dat agram t akes from source t o dest inat ion. This t racerout e program is sim ilar in funct ion t o t he Windows Tracert ; inst ead of using I CMP t o discover t he rout ers and dest inat ion host , however, it uses UDP. The int erm ediat e rout ers t hat are discovered respond as you saw in t he Windows Tracert wit h I CMP " t im e- exceeded in- t ransit " m essages when an I P dat agram has a TTL value decrem ent ed t o 0. Again, t his process is repeat ed unt il t he UDP dat agram m akes it s way t o t he dest inat ion host by increm ent ing t he st art ing TTL value by 1 for each new hop t o be forged beyond t he previous one. The UDP dest inat ion port chosen is one t ypically in t he 33000–33999 range—one t hat alm ost surely does not list en. The int ent ion is t o elicit an I CMP " UDP port unreachable" m essage t hat signals t o t racerout e t hat t he dest inat ion host has been found. Like t racert , t he default behavior for t racerout e is t o send t hree different connect ions t o each rout er or host . This exam ple alt ers t he behavior t o send only one for sim plicit y:

tracer.com.62615 > target.com.33456: udp 12 (DF) [ttl 1] router.com > tracer.com: icmp: time exceeded in-transit [tos 0xc0] tracer.com.62615 > target.com.33457: udp 12 (DF) target.com > tracer.com: icmp: target.com udp port 33457 unreachable (DF)

I n t he preceding out put , you see t racer.com send a UDP dat agram t o dest inat ion port 33456 of t arget .com . The init ial TTL value is set t o 1. As soon as t his packet hit s rout er.com , it decrem ent s t he TTL value t o 0 and ret urns an I CMP " t im e exceeded in t ransit " m essage t o t racer.com . When t racer.com receives t his, it sends anot her UDP dat agram t o t arget .com . This is different from t he first one

because it increm ent s t he dest inat ion port t o 33457 and, while you cannot t ell from t he st andard TCPdum p out put , it increm ent s t he init ial TTL t o 2. This allows t he dat agram t o t raverse t he first rout er, rout er.com , and t ake one m ore hop. That addit ional hop t akes it t o t he dest inat ion host t arget .com t hat does not list en on port 33457 and ret urns an I CMP " port unreachable" m essage. You should be aware t hat bot h t he UNI X t racerout e and t he Windows t racert only work if specific I CMP m essages are allowed int o t he net work of t he host execut ing t he com m ands. Bot h versions require t hat I CMP " t im e exceeded in- t ransit " m essages be allowed int o t he net work. The UNI X t racerout e requires t hat I CMP " port unreachable" m essages be allowed, and Windows t racert requires t hat I CMP echo request s be allowed. You are probably asking whet her t hese t ypes of I CMP m essages should be perm it t ed inbound t o your net work. This really depends on t he securit y post ure you adopt . At t he m ost prot ect ed and rest rict ed sit es, t his is not necessarily recom m ended. The risks m ight far out weigh t he benefit s because it is possible t o use t hese I CMP m essages for purposes ot her t han t he ones for which t hey were designed, as was wit nessed wit h t he discussion of Loki in Chapt er 4. However, if your sit e is a m ore open one and you are willing t o accept t he risks, allowing t hese I CMP m essages can provide som e obvious benefit s of rout e discovery along wit h inform at ive feedback t o int ernal host s in your net work. Su m m a r y of Ex pe ct e d Be h a vior a n d Pr ot ocol Be n de r s Here is a brief synopsis of what has been covered so far in t his chapt er. The RFCs are t he st andards docum ent s upon which TCP/ I P and t he I nt ernet were built . They describe how t hings are supposed t o work when everyone conform s t o t he sam e rules. Unfort unat ely, hackers have discovered t hat different im plem ent at ions of TCP/ I P react different ly t o deliberat e violat ions of t he RFC st andards. That 's one of t he foundat ions of hacking: deliberat ely exploit ing except ional condit ions t hat t he im plem ent ers of t he TCP/ I P code believed would never happen. Hackers oft en at t em pt t o ident ify operat ing syst em s by sending st range st im uli and observing t he host 's responses. The final part of t his chapt er looks at som e of t he react ions of syst em s t o t hese deliberat e deviat ions. As previously discussed, t here are unique responses for t he sam e st im ulus depending on t he circum st ances and availabilit y of t he request ed service. Responses also depend on a host or rout er's capabilit y t o respond t o a part icular connect ion. Each of t he different prot ocols has different expect ed responses. Finally, you see in prot ocol benders som e unusual, but not abnorm al, behavior exhibit ed by som e applicat ions.

Abn or m a l St im u li

This sect ion exam ines som e of t he blat ant ly anom alous behaviors t hat hackers m ight t hrow your way. These behaviors have m any purposes, and each is exam ined for t he different cat egories discussed. These cat egories and anom alies are not all- inclusive; you m ight find m any m ore. Eva sion St im u lu s, La ck of Re spon se You see a port scan of vict im .org from st ealt hy.com wit h t he FI N flag alone set in t he TCPdum p out put t hat follows. This is a sneaky way of det erm ining whet her a given port is act ive. The expect ed behavior per RFC 793 is t hat a list ening port t hat is scanned should not respond; a port t hat is not list ening should respond wit h a RESET/ ACK. This m aps t he services t hat a t arget host offers. Take a look:

stealthy.com.50141 stealthy.com.50141 stealthy.com.50141 stealthy.com.50141 stealthy.com.50141 stealthy.com.50141 stealthy.com.50141 stealthy.com.50141 stealthy.com.50141 stealthy.com.50141 stealthy.com.50141

> > > > > > > > > > >

victim.org.5: F 0:0(0) win 4096 (DF) victim.org.3: F 0:0(0) win 4096 (DF) victim.org.26: F 0:0(0) win 4096 (DF) victim.org.45: F 0:0(0) win 4096 (DF) victim.org.17: F 0:0(0) win 4096 (DF) victim.org.7: F 0:0(0) win 4096 (DF) victim.org.51: F 0:0(0) win 4096 (DF) victim.org.52: F 0:0(0) win 4096 (DF) victim.org.30: F 0:0(0) win 4096 (DF) victim.org.53: F 0:0(0) win 4096 (DF) victim.org.20: F 0:0(0) win 4096 (DF)

The reason t hat t his scan is considered m ore st ealt hy t han a scan t hat probes port s wit h an at t em pt ed SYN connect ion is t hat som e int rusion det ect ion syst em s m ight not pick up a FI N scan. Hist orically, probes of open port s were done using SYN scans, and earlier int rusion det ect ion syst em s were developed using t his signat ure. When t he hackers realized t hat t heir scans were being det ect ed, however, t hey t ried t o elude not ice by launching FI N scans t hat would m ap t he act ive port s but m ight not be not iced. This scan can be launched using nm ap –sF vict im .org t o inform nm ap t o do a st ealt hy FI N scan. Evil St im u lu s, Fa t a l Re spon se Denial- of- service ( DoS) at t acks m ight at t em pt t o st arve a host of resources needed t o funct ion correct ly. There are m any different variet ies of DoS at t acks. Jolt 2 is an at t ack t hat consum es so m uch of t he t arget host 's m em ory resources t hat it cannot funct ion. Here is som e sam ple out put from Jolt 2:

10:48:56.848099 10:48:56.848099 10:48:56.848295 10:48:56.848295 10:48:56.848351 10:48:56.848351

verbo.com verbo.com verbo.com verbo.com verbo.com verbo.com

> > > > > >

win98.com: win98.com: win98.com: win98.com: win98.com: win98.com:

(frag (frag (frag (frag (frag (frag

1109:9@65520) 1109:9@65520) 1109:9@65520) 1109:9@65520) 1109:9@65520) 1109:9@65520)

10:48:56.848420 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848420 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848584 verbo.com > win98.com: (frag 1109:9@65520)

Jolt 2 sends an endless st ream of I CMP echo request s ( by default , alt hough ot her prot ocols can be used) t o a t arget Windows host . These are sent as fragm ent s wit h t he sam e fragm ent I D but also wit h duplicat e non- zero fragm ent offset s. Because all fragm ent s but t he first in t he fragm ent t rain carry only dat a, not prot ocol headers, t he receiving host only knows t he em bedded prot ocol is I CMP. A problem exist s for cert ain Windows 98, Windows NT, and Windows 2000 host s when t hey do not receive t he init ial 0 offset fragm ent . The t arget host becom es consum ed wit h packet reassem bly, and m em ory usage shoot s way up leading t o a DoS. When looking at t he TCPdum p out put of t he Jolt 2 act ivit y, all you know is t hat host verbo.com is sending som e kind of packet s t o t he win98.com host . You see a repeat ed fragm ent I D of 1109, a fragm ent lengt h of 9, and a fragm ent offset of 65520. The Jolt 2 source code assigns t he fragm ent offset a st at ic value of 65520. This brings t he t ot al close t o t he 65535 m axim um . I nit ially, you m ight t hink t his worked because of t he fragm ent offset num ber. However, when t his value was changed in t he source code t o som et hing quit e a bit lower and t he code was recom piled, t he DoS st ill occurred. To t est t he response of t he t arget host , a ping process was execut ed on t he m alicious host verbo.com t o win98.com before and during t he t im e t he Jolt 2 code was run. The DoS was alm ost im m ediat e aft er t he Jolt 2 code was execut ed. The win98.com host neit her responded t o pings nor keyboard input . I t recovered aft er t he at t ack was st opped and did not require reboot ing.

Th e M ot iva t ion Be h in d Sca n n in g One of t he first phases in any at t em pt t o break int o a host on a net work is t o do som e kind of reconnaissance on t he net work or a part icular host . An at t acker m ight have a new piece of code t hat was j ust released t hat enables him t o get root access if he can find a vulnerable host . Or, an at t acker m ight j ust be int erest ed in get t ing int o a host or m ult iple host s in any way possible. Different hackers have different goals for hacking. Perhaps t he host or net work is being sought t o part icipat e in a dist ribut ed denial- of- service at t ack. Or, perhaps t he int erest is in com prom ising a host from which t o launch ot her at t acks and hide t he t rue ident it y of t he hacker. The at t acker m ust scan t he net work in som e fashion t o discover live host s, and lat er discover host s suscept ible t o exploit s by scanning service port s. For inst ance, t he at t acker m ight have acquired som e soft ware t hat

could gain root access on host s offering vulnerable DNS servers. Chances are good t hat he would scan t he net work for any host list ening on t he DNS port . Aft er discovering t hose, t he at t acker m ight t ry t o execut e t he DNS exploit code on host s running DNS. The scanning phase is one t hat m ight be done blat ant ly at night when it is less likely t hat a net work is being wat ched. I t m ight be done from a com prom ised host so t hat when it is discovered, t he at t acker's ident it y will not be known. Or, t he hacker m ight t ry t o launch t he scans using m et hods t hat m ight go undet ect ed, known as st ealt h scans. These scans are considered m ore furt ive because t hey use unconvent ional t echniques t hat NI DS are not likely t o pick up. Som e of t he scanning t echniques also at t em pt t o fingerprint t he operat ing syst em . Many t im es a given exploit m ight plague a subset of operat ing syst em s. For t he hacker t o have a bet t er chance of success, reconnaissance m ust be done t o find host s running a part icular operat ing syst em . N o St im u lu s, All Re spon se This is really j ust a fancy nam e for I P spoofing. Appendix A, " Exploit s and Scans t o Apply Exploit s," discusses t his in m ore det ail. I n t he following TCPdum p out put , it appears t hat m any 1.2 host s are receiving I CMP " t im e exceeded in- t ransit " m essages. They are being inform ed t hat t raffic, which t hey sent t o a host , had a TTL expire in a dat agram . Nat urally enough, t his im plies t hat all t he 1.2 host s sent som e kind of t raffic t hat elicit ed t hese responses. That is not t he case, however; no out bound t raffic is found from t hese host s. Here is t he out put :

router.com router.com router.com router.com router.com router.com router.com router.com router.com

> > > > > > > > >

1.2.10.72: icmp: time exceeded in-transit 1.2.18.13: icmp: time exceeded in-transit 1.2.11.67: icmp: time exceeded in-transit 1.2.16.13: icmp: time exceeded in-transit 1.2.19.1: icmp: time exceeded in-transit 1.2.1.252: icmp: time exceeded in-transit 1.2.13.56: icmp: time exceeded in-transit 1.2.143.6: icmp: time exceeded in-transit 1.2.13.15: icmp: time exceeded in-transit

Can you guess t he explanat ion for t his t raffic? Given t he t it le of t he sect ion, it should be a no- brainer. The 1.2 host s were spoofed, and t raffic was sent t o a foreign net work using t hem as a source I P. The reason for t his is sheer speculat ion because you see only one side of t he act ion; however, t he m ost likely explanat ion is t hat som e kind of flood of act ivit y or harassm ent against t he foreign net work was undert aken. How do you know t hat source I P rout er.com is not doing som e kind of reconnaissance of t he dest inat ion 1.2 host s? Couldn't t his t ype of t raffic elicit som e

kind of response from a rout er, if not a host ? The problem is t hat t his is an I CMP error m essage, and RFC 1122 dict at es t hat an I CMP error m essage cannot elicit anot her I CMP error m essage because t hat m ight lead t o som e kind of endless loop when an error condit ion was encount ered. Because no ot her prot ocol would respond t o t his act ivit y, t he spoofing t heory is t he m ost logical.

Ba ck sca t t e r A very int erest ing st udy was conduct ed and a paper was writ t en about at t acks such as t he one discussed in t he sect ion, " No St im ulus, All Response." The aut hors nicknam ed t he at t acks backscat t er. The aut hors st udied act ivit y on t heir class A net work on t he I nt ernet over an ext ended t im e. They were able t o infer backscat t er at t acks on t he I nt ernet by exam ining different prot ocol responses for which t here were no request s. This indicat ed t hat I P addresses from t heir net work were being spoofed. Using t his inform at ion, t hey were able t o deduce t he num ber and t ypes of at t acks t hat occurred on t he I nt ernet during t hat t im e. The frequency and t ypes of act ivit y occurring on t he I nt ernet are pret t y am azing. The st udy, " I nferring I nt ernet Denial- of- Service Act ivit y," can be found at www.cs.ucsd.edu/ ~ savage/ papers/ UsenixSec01.pdf. Un con ve n t ion a l St im u lu s, Ope r a t in g Syst e m I de n t ifyin g Re spon se This sect ion discusses som e exam ples of at t em pt s t o fingerprint t he operat ing syst em of a t arget host by sending unconvent ional st im uli and t hen evaluat ing t he t arget host 's responses. The nm ap program is one scanning t ool t hat can rem ot ely at t em pt t o ident ify a t arget host 's operat ing syst em . The reason t hat m alicious hackers at t em pt t o ident ify a host 's operat ing syst em is because t hey can t hen pair appropriat e exploit s wit h vulnerable operat ing syst em s. I t is pot ent ially dam aging reconnaissance inform at ion if som eone can det erm ine t he operat ing syst em of a rem ot e host . Sure, som e sit es are open enough t hat t he operat ing syst em t ype and version can be harvest ed from banners associat ed wit h t elnet or FTP connect ions. These m ight not be readily available for all sit es, however; and even if t hey are, t hey m ight not be accurat e. Every operat ing syst em has a TCP/ I P st ack im plem ent at ion t hat differs slight ly. I f a hacker or soft ware can send specific packet s, knowing how a part icular operat ing syst em should respond, t he hacker can t ell Linux from Solaris, ( som et im es) wit hout requiring any ot her inform at ion. nm ap sends som e unexpect ed st im uli, including t he following, t o ident ify a host 's operat ing syst em based on t he replies: z

An unsolicit ed FI N t o an open port . There should be no response according t o RFC 793, but som e host s do respond wit h a RESET. The out put was exam ined in t he previous sect ion, " Evasion St im ulus, Lack of Response," t o show how

t his t raffic can be used t o m ap list ening port s wit h m ore st ealt h t han convent ional SYN scans. z

z

z

Bogus " reserved" TCP flag values. nm ap sends t hese t o see whet her t he t arget host reset s t he bit s t o 0 for t hose nonexist ent flags. Many operat ing syst em s t hink t hese bit s are bogus; however, t hose t hat are ECN- aware m ight not , as discussed in t he following sect ion. Anom alous TCP flag com binat ions. Mut ant flag com binat ions are sent wit h t he expect at ion t hat m ost t arget host s will not respond, but a handful m ight respond, uniquely ident ifying t heir operat ing syst em . No TCP flag values. nm ap sends t hese t o see how t he t arget host handles t his anom alous sit uat ion.

Bogus " Re se r ve d" TCP Fla gs

One fingerprint ing m et hod is t o send bogus TCP flag set t ings. Figure 5.1 shows t he configurat ion of t he TCP flag byt e. The TCP flag byt e cont ains all t he possible TCP flag set t ings. Rem em ber from Chapt er 2, " I nt roduct ion t o TCPdum p and TCP t hat t he TCP flag set t ings t ell m uch about t he purpose of a given TCP segm ent . Because t here are only six TCP flags, t here are 2 ext ra bit s in t he TCP flag byt e. Before t he invent ion of som et hing known as Explicit Congest ion Not ificat ion ( ECN) , t hese high- order reserved bit s were expect ed t o have a value of 0. ECN is discussed m ore t horoughly in Chapt er 9. Figu r e 5 .1 . TCP fla g by t e .

To exam ine all t he bit s set in t he TCP flag byt e, you need t o execut e t he st andard version of TCPdum p wit h t he - x opt ion t hat dum ps t he collect ed dat agram in hexadecim al. You cannot check t he value of t he 2 high- order bit s wit h st andard TCPdum p out put . A byt e is represent ed as t wo hexadecim al charact ers, or nibbles. The low- order nibble cont ains t he bit set t ings for t he PUSH, RESET, SYN, and FI N flags. Turn your at t ent ion t o t he high- order nibble t o exam ine t he value of t he reserved bit s. The bogus TCP flag set t ings t hat nm ap t est s at t em pt t o give t hese bit s a value. I f t he high- order nibble has a value great er t han 3, t his indicat es t hat one or bot h of t he reserved bit s are set . You can arrive at t his value because t he ACK bit when set has a value of 1 t im es 2 0 ( or 1) and t he URG bit when set has a value of 1 t im es 2 1 ( or 2) . These t wo values com bined equal 3. Any value great er t han 3 in

t he high- order nibble is anom alous unless ECN is being used. The following TCPdum p out put shows an nm ap scan t hat at t em pt s t o discover m ore about t he behavior of t he TCP/ I P st ack of t arget .com t o help ident ify t he operat ing syst em . This part icular at t em pt ed connect ion set one of t he reserved TCP flag byt es—specifically, t he bit t o t he left of t he URG bit . First , you see t he regular TCPdum p out put , but it gives no clue t o t he underlying bogus TCP flag bit set t ings. The following hexadecim al out put shows all fields, including t he TCP flag byt e field:

scanner.com.44388 > target.com.domain: S 403915838:403915838(0) win 4096 (DF) [4500 003c 7542 4000 3b06 15bd 0102 0304 0102 0305] ad64 0035 1813 443e 0000 0000 a042 1000 fa4c 0000 0303 0a01 0204 0109 080a 3f3f 3f3f 0000 0000 0000

Looking at t he hexadecim al out put , t he first 20 byt es of t he I P header are in bracket s. The TCP header and any dat a follow t his; t he 13t h byt e int o t he TCP header ( m arked in bold) is t he TCP flag byt e. You see t hat t he value is a hexadecim al 42. Looking at t he high- order nibble ( or t he value of 4) , it is great er t han 3, m eaning t hat t he low- order reserved bit has been set . The scanner's hope is t hat t he response t o t his bogus flag set t ing indicat es som et hing unique about t he operat ing syst em . Now, t ake a look at t he response of t arget .com t o scanner.com . Our int erest and nm ap's int erest is t he response t o t he bogus TCP flag bit set . Again, t he norm al TCPdum p out put display does not show t he reserved bit s of t he TCP flag byt e. The hexadecim al dum p t hat does show t he TCP flag byt e follows t his:

target.com.domain > scanner.com.44388: S 4154976859:4154976859(0) ack 403915839 win 8855 (DF) [4500 003c e04e 4000 ff06 e6af 83da d684 83da d683] 0035 ad64 f7a7 ea5b 1813 443f a012 2297 fd3f 0000 0101 080a 0102 0f9f 3f3f 3f3f 0103 0300 0204 0109

Look at t he response t o t he bogus TCP flag bit s in t he preceding TCPdum p out put . t arget .com responds wit h a SYN/ ACK—not hing rancid here. I t appears t hat t arget .com did not react t o t he abnorm al TCP flag bit set . How do you know? The hexadecim al out put of t he t ransact ion shows t hat t he response has t he SYN and ACK bit set in t he TCP flag byt e wit h a hexadecim al value of 12 ( in bold) . The ACK bit is in t he low - order bit of t he high- order nibble, so it represent s t he value 1. The

SYN bit is in t he low- order nibble, second bit from t he left , and represent s t he 2 value. Therefore, t he response discarded t he bogus TCP flag bit . Anot her operat ing syst em m ight have preserved t hat bit , and it would have been reflect ed in t he TCP flag byt e. An om a lous TCP Fla g Com bin a t ion s RFC 793 elaborat es norm al TCP flag st at e set t ings and t ransit ions in ext ensive det ail. I t seem s likely t hat m ost operat ing syst em TCP/ I P st acks would conform t o t he specificat ions. For t he m ost part , t hey do, but t here are t he rare except ions t hat do not conform and are t herefore ident ifiable by t heir lack of conform it y. Look at t he following TCPdum p out put from an excerpt of t raffic produced by running nm ap in operat ing syst em fingerprint ing m ode ( - O com m and line opt ion) for a host nam ed win98:

nmap –O win98 20:33:16.409759 verbo.47322 > win98.netbios-ssn: SFP 861966446:861966446(0) win 3072 urg 0 20:33:16.410387 win98.netbios-ssn > verbo.47322: S 49904150:49904150(0) ack 861966447 win 8215 (DF)

The scanning host sends a packet wit h t he TCP flags of SYN, FI N, and PUSH sim ult aneously set . Logically, it appears t hat t his is an anom alous flag t rio because a SYN flag st art s a connect ion, a FI N flag closes a connect ion, and a PUSH flag sends dat a aft er a connect ion is opened or before a connect ion is closed. I t would seem a nat ural react ion t hat a host receiving t his connect ion would ignore it or perhaps RESET it because it m akes no sense.Yet , t he Windows 98 t arget host appears t o int erpret t his as session est ablishm ent and responds wit h a SYN and an ACK. This unique react ion helps ident ify t he responding host as having a Windows TCP/ I P st ack. N o TCP Fla gs

As anot her exam ple of nm ap fingerprint ing, look at t he following TCPdum p out put . I t shows a TCP segm ent wit h no TCP flag bit s set . This is anot her inst ance of sending a m ut ant TCP flag byt e set t ing. I n t his case, no flag bit s have been t urned on; t his is also known as a null session:

scanner.com.44389 > target.com.domain: . win 4096 (DF) [4500 003c 7543 4000 3b06 15bc 0102 0304 0102 0305] ad65 0035 1813 443e 0000 0000 a000 1000 fa8d 0000 0303 0a01 0204 0109

080a 3f3f 3f3f 0000 0000 0000

Look at t he previous hexadecim al out put . The TCP flag byt e field, which is in bold, has a value of 00. This m eans t hat no TCP flags have been set . Most host s will not respond t o a null session, yet som e m ust , ot herwise nm ap would have no reason t o send t his kind of t raffic. A norm al TCP flag byt e has at least one flag bit set . The host t arget .com did not respond at all t o t his null session TCP segm ent . The lack of response provides som e clue about t he operat ing syst em . Anot her operat ing syst em m ight dist inguish it self by responding different ly, perhaps by replying wit h a RESET.

Usin g TCP Opt ion s for OS I de n t ifica t ion Look at t he following TCPdum p out put from an nm ap scan wit h t he focus on t he bolded TCP opt ions:

scanner.com.44388 > target.com.domain: S 403915838:403915838(0) win 4096 (DF) target.com.domain > scanner.com.44388: S 4154976859:4154976859(0) ack 403915839 win 8855 (DF)

One of t he ot her m et hods t hat nm ap uses t o ident ify a part icular operat ing syst em is t o send m any different TCP opt ions. Som e operat ing syst em s do not support all t hese opt ions, and t he response discards som e. Also, som e operat ing syst em s set different values for som e of t he TCP opt ions, furt her different iat ing t he fingerprint . Unlike t he ot her exam ples discussed so far, t hese are not unconvent ional st im uli, but are m ent ioned because t hey help ident ify t he rem ot e operat ing syst em . Finally, different operat ing syst em s will st ore t hese opt ions in a different order in t he TCP header, which is indicat ed by t he order in which TCPdum p list s t hem . All t his inform at ion can cont ain a bount y of ident ifying clues. As you see in t he response t o t he preceding opt ions, t he order has been changed and som e of t he values have been alt ered ( such as t he wscale changing from 10 t o 0 in t he response) . Also not ice t hat t he nop and eol opt ions are rearranged or disappear in t he response. These fields are used t o pad TCP opt ions t o 4- byt e boundaries and m ight not be needed in t he response. For an in- dept h discussion of TCP opt ions, t ake a look at RFC 1323. Som e of t he TCP opt ions seen in t he TCPdum p out put are as follows:

z

-wscale.

z

-timestamp.

z

-nop.

z

-eol.

This opt ion allows t he TCP window size t o increase t o a value great er t han 65535 byt es. This is t ypically used t o increase t hroughput of TCP over high- bandwidt h, long- delay net works. This opt ion records round- t rip t im e m easurem ent s. These m easurem ent s are oft en necessary t o opt im ize t hroughput based on changes in net work condit ions. This opt ion is used t o add a 1- byt e pad t o TCP opt ions. TCP opt ions m ust fall on 4- byt e boundaries; and if t hey are less t han 4 byt es, t he nop is used t o pad. This is t he end- of- list opt ion used t o pad a final byt e t o a 4byt e boundary.

Su m m a r y of Abn or m a l St im u li You see t hat t here are m any variat ions of abnorm al act ivit y. Different t ypes of abnorm al act ivit y have different purposes. Som e t ry t o evade t he vigilant eye of NI DS or circum vent filt ering. Ot hers are blat ant ly host ile because t hey at t em pt a denial of service against a t arget host . You m ust also be aware t hat som et im es what you m ight perceive t o be host ile act ivit y is act ually a response from a host responding t o your spoofed addresses. Finally, program s, such as nm ap, use unique st im uli t o elicit responses wit h ident ifying charact erist ics of t he t arget operat ing syst em

Su m m a r y As far as expect ed responses are concerned, rem em ber t here are no absolut es. Not every operat ing syst em 's TCP/ I P st ack is from t he sam e m old shaped by a set of ident ical defining RFCs. Som e operat ing syst em s do not follow t he RFCs' expect ed behavior. This does not necessarily indicat e som e kind of m ut ant response. This is m ore a reflect ion of a lack of st andardizat ion. There is a very im port ant point t o learn from st im ulus- response t heory. A com m on knee- j erk react ion from observing t raffic t hat appears t o be som e kind of scan or repeat ed act ivit y direct ed against your net work is t o j um p t o t he im m ediat e conclusion t hat you are under at t ack from t he source I P. You are likely t o label t he source I P as t he aggressor. Take a m om ent and t hink before you aut om at ically m ake such an assessm ent . Grant ed, m any t im es you will be correct . But , t hink about t he possibilit y t hat t his was an elicit ed response. ( There m ight have even been som e kind of cat alyst t o which t he alleged aggressor is responding.) For inst ance, your source I Ps m ight have been spoofed. This concept is easy t o assim ilat e in t heory, but hard t o rem em ber in pract ice.

Conversely, when you get som e kind of response act ivit y, such as an unsolicit ed I CMP echo reply, it is very possible t hat t he source host is indeed t he aggressor. As discussed in Chapt er 4, t he Tribe Flood Net work ( TFN) at t ack uses an I CMP echo reply as t he com m unicat ion vehicle bet ween t he m ast er and daem ons t o launch or cont rol a dist ribut ed denial of service ( DDoS) at t ack. I f you have any doubt about observed act ivit y, t he best advice is t o exam ine t he ent ire capt ured dat agram and scrut inize t he header fields and payload for anom alies.You have t o adopt t he at t it ude t hat not hing is predict able all t he t im e when you exam ine net work t raffic.

Ch a pt e r 6 . D N S

Why devot e an ent ire chapt er t o DNS? I sn't DNS used t o t ranslat e a host nam e t o an I P address and t hat 's about it ? Sure, t hat is a big and im port ant part of DNS, but DNS is m uch m ore. DNS servers are probably one of t he m ost com m on t arget s of reconnaissance and exploit effort s. Your DNS server is a cherished prize for a hacker t o com prom ise, so hackers are going t o see how vulnerable it is by pounding on it for weaknesses. DNS servers are t arget ed for t he following reasons: z

z

z

DNS servers can provide a lot of reconnaissance inform at ion about host s in preparat ion for launching an at t ack of a t arget ed net work. DNS is used t o resolve host nam es and I P addresses; so if a hacker can dupe a DNS server or act ually seize cont rol of a DNS server, she can m anipulat e nam e or address t ranslat ions for m alicious purposes. Oft en, weak m et hods of aut hent icat ion rely on a host having a part icular host nam e or I P address. I f norm al t ranslat ions can be subvert ed, aut hent icat ions can be corrupt ed. DNS servers are accessible and inform at ion sharing ent it ies. The port com m only associat ed wit h DNS t raffic, UDP port 53, is oft en left open on packet - filt ering devices so t hat int ernal nam e servers can funct ion.

This chapt er covers t hese t opics along wit h DNS t heory and pract ical applicat ions. You learn how DNS queries are answered, how DNS servers int eract wit h ot her DNS servers, how DNS can be used t o discover inform at ion about a sit e, and ways t hat DNS can be used for exploit purposes. I n short , t his inform at ion will aid you in applying net work securit y and analyzing t he nat ure of DNS t raffic seen on t he net work.

Ba ck t o Ba sics: D N S Th e or y

Again, TCPdum p is enlist ed t o help explain and visualize what occurs wit h different t ypes of DNS t ransact ions. Specifically, t his sect ion exam ines how a DNS query is issued and answered. DNS differs from a norm al client / server applicat ion, such as t elnet , where t he client request s a connect ion t o a desired server and t he int eract ion is bet ween t hose t wo host s. For DNS, however, when a client issues a DNS query, a DNS server accept s t he query, perhaps int eract s wit h one or m ore addit ional DNS servers, and t hen ret urns t he response t o t he client . This sect ion looks at t he st ruct ure of DNS as a dist ribut ed syst em , and it exam ines host nam e t o I P address resolut ion. I t also discusses t he role of m ast er ( form erly known as prim ary) and slave ( form erly known as secondary) nam e servers and discusses t he int eract ion bet ween t hem . You learn t hat unlike ot her services, DNS can swit ch bet ween UDP and TCP prot ocols, depending on t he kind of DNS act ivit y. Th e St r u ct u r e of D N S DNS is a globally dist ribut ed syst em t hat depends on t he cooperat ive int eract ion of m any DNS servers t o st ore records about " dom ains" and t o com m unicat e wit h each ot her. A dom ain is a subset of DNS records associat ed wit h a logical grouping. For inst ance, sans.org is a collect ion of records cont aining I P addresses, host nam es, nam e servers, and m ore associat ed wit h t he sans.org dom ain. Figure 6.1 depict s t he hierarchical nat ure of DNS. Figu r e 6 .1 . D N S, t h e pyr a m id sch e m e .

Logically, t he t op node of t he DNS t ree is known as root —designat ed by t he period ( .) . Funct ionally, t his is represent ed by root servers t hat can act as t he st art ing point for DNS resolut ions. These servers j ust point t o ot her DNS servers t hat m ight have dom inion over t he DNS records being sought . You are probably fam iliar wit h t he t op- level dom ains, t hose falling direct ly under t he root servers ( t he long- est ablished .edu, .org, .com , .net , .m il, and .gov; and t he recent ly

est ablished .aero, .biz, .coop, .info, .m useum , .nam e, and .pro, t o nam e t he dom est ic dom ains) . There are addit ional t op- level dom ains for foreign count ries, such as .j p for Japan. St e ppin ' Ou t on t h e I n t e r n e t Suppose t hat you want t o visit www.sans.org, which is t he hom e page for t he Syst em Adm inist rat ion, Net working, and Securit y ( SANS) I nst it ut e. You ent er www.sans.org in your browser, and seconds lat er you see t he www.sans.org page. Now, rem em ber t hat I P dat agram s use I P addresses for all source and dest inat ion addresses. I P knows not hing about host nam es. The hum an m ind is m ore likely t o rem em ber t hat t he capit al of Florida is Tallahassee, t han it is t o rem em ber t he value of pi t o 10 fract ional digit s is 3.1415926536, even t hough bot h t ake 11 charact ers ( excluding t he decim al) t o represent . Nam es have m ore order and less random ness t han num bers, so you t end t o rem em ber t hem bet t er. This is why you speak in host nam es rat her t han I P addresses. I t is apparent t hat som e kind of t ranslat ion m echanism is required bet ween t he way you reference host s ( via host nam es) and t he way TCP/ I P m ust reference host s ( via I P addresses) . So, how did t his t ranslat ion from www.sans.org t o an I P address m yst eriously occur behind t he scenes? Before you could even send out a request t o www.sans.org, your host had t o know an I P address. Your host needs t his I P address t o insert int o t he dat agram when it sends t he connect ion request t o www.sans.org out on t he net work. The following sect ion unveils t his som ewhat t ransparent process.

Re cu r sive Ve r su s I t e r a t ive Qu e r ie s DNS queries com e in t wo different variet ies: recursive and it erat ive. A recursive query requires a nam e server t o find t he answer t o t he query it self. I n ot her words, it m ight query nam e servers, such as root nam e servers t hat do not know t he answer t o t he query but know references of nam e servers t hat possibly have t he answer t o t he query. The nam e server m ust follow all t he references unt il it finds a nam e server t hat has t he answer. The bot t om line is t hat a recursive query asks t he queried DNS server t o be t he workhorse and finds an answer while t he querying DNS server wait s for t he answer or perform s unrelat ed queries. An it erat ive query asks a nam e server t o fet ch t he answer t o a query. I f t he nam e server doesn't have t he answer, it ret urns t o t he querying nam e server a reference of anot her nam e server t hat possibly has t he answer t o t he query. The queried nam e server does not pursue finding t he answer; t he querying nam e server m ust pursue finding t he answer t o t he query it self. D N S Re solu t ion Pr oce ss

Figure 6.2 shows t he beginning of t he process of resolut ion from host nam e www.sans.org t o I P address. Figu r e 6 .2 . Clie n t r e solve r , t he h a n doff.

You see your browser is on host .m y.com and it at t em pt s resolut ion of www.sans.org. Assum ing t hat your host is not a nam e server, it is m ost ly passive t hroughout t he resolut ion process. I t j ust fires off t he request for t he t ranslat ion and resum es t he process of connect ing t o t he www.sans.org page aft er it receives a resolut ion of t he I P address. The workhorse behind t he resolut ion process is t he DNS server t hat is queried ( in t his case, dns.m y.com ) . Generally, a default nam e server is chosen at t he t im e t he operat ing syst em is inst alled on a given client m achine. On UNI X m achines, t he inform at ion is st ored in t he file / et c/ resolv.conf. The DNS server is set as a TCP/ I P propert y in t he Net work port ion of t he Cont rol Panel for Windows host s. This default DNS server t ypically is m anaged locally and is locat ed som ewhere on your organizat ion's int ranet . dns.m y.com is t his sit e's DNS server. On t he client host , t he TCP/ I P applicat ions, such as t elnet , FTP, Net scape, or I nt ernet Explorer, call " resolver" library rout ines t o obt ain DNS resolut ion. When you request ed www.sans.org, applicat ion soft ware issued a call t o resolve t he host nam e t o an I P address. I n t his case, a get host bynam e call is sent from host .m y.com t o t he DNS server. This request s host nam e t ranslat ion of www.sans.org t o an I P address. The DNS server receives t his request , processes it , and ret urns it t o host .m y.com . Figure 6.3 shows t he second part of t he resolut ion j ourney aft er leaving host .m y.com . You see dns.m y.com assum es t he act ual t ask of finding t he answer of t he I P of www.sans.org. For sim plicit y of t heory ( alt hough t his m ight be perceived as adding com plexit y t o t he act ual resolut ion process) , assum e t hat dns.m y.com knows not hing about www.sans.org or any ot her host in t he .org dom ain.

dns.m y.com begins it s search wit h a DNS root server t o find t he resolut ion. Figu r e 6 .3 . D N S se r ve r r e solu t ion , t h e cr y for h e lp.

I f a DNS server has t o resolve an unknown ext ernal host nam e and it has no knowledge of t he host 's associat ed dom ains, it m ust cont act a root nam e server. Root nam e servers are m ore t han j ust a st art ing point —t hey m aint ain a m apping bet ween dom ain nam es ( sans.org) and t he aut horit at ive nam e servers—DNS servers t hat m aint ain DNS records for t hose dom ains. When t he local nam e server, dns.m y.com , asks a root nam e server for t he I P address of www.sans.org, it get s back a referral t o t he nam e servers for sans.org. You m ight ask how dns.m y.com knows t he nam es and I P addresses of t he root servers t o cont act . Obviously, t he local nam e server m ust be preconfigured wit h a list of known root nam e servers. This inform at ion is m aint ained by t he I nt erNI C and m ay be downloaded from ft p: / / ft p.rs.int ernic.net / dom ain/ nam ed.ca. Cont inuing t he resolut ion advent ure, t he root server let s dns.m y.com know where t o cont inue it s search. The root server has ret urned a referral t o t he nam e server server1.sans.org as an aut horit at ive nam e server for www.sans.org. Figure 6.4 depict s dns.m y.com querying server1.sans.org and receiving an aut horit at ive answer, t he I P address of 12.33.247.6. Figu r e 6 .4 . D N S se r ve r r e solu t ion , fr om t h e h or se 's m ou t h

TCPdu m p Out pu t of Re solu t ion

You can exam ine t he t raffic t hat t his DNS request generat ed by observing t he TCPdum p out put t hat follows:

host.my.com.1716 > dns.my.com.53: 1+ (35) dns.my.com.53 > h.root-servers.net.53: 12420 (30) (DF) h.root-servers.net.53 > dns.my.com.53: 12420- 0/3/3 (153) (DF) dns.my.com.53 > server1.sans.org.53: 12421+ (30) (DF) server1.sans.org.53 > dns.my.com.53: 12421* 1/3/3 (172) dns.my.com.53 > host.my.com.1716: 1* 1/3/3 (197) (DF)

First , host .m y.com ( t he client exchanges from host .m y.com are in bold) issues t he request t o resolve www.sans.org t o dns.m y.com . TCPdum p analyzes DNS at t he applicat ion level, which is why you don't see t he word udp em bedded in t he out put even t hough t his is UDP. UDP is t he prot ocol select ed for t he t ransm ission of t he m aj orit y of DNS t raffic because t he queries and responses are oft en short and t he applicat ion it self can t olerat e lost dat a. When ant icipat ed dat a is not received, t he DNS query is reissued. Next , dns.m y.com at t em pt s a connect ion t o h.root - servers.net on port 53. Not ice t hat bot h source and dest inat ion port s are 53. h.root - servers.net responds back t o dns.m y.com using source and dest inat ion port s 53 as well. A discussion of t he num bers and not at ions found at t he end of each TCPdum p record is found in t he next sect ion, " St range TCPdum p Not at ion." h.root - servers.net does not have t he answer t o t he query. I t has a reference of anot her DNS server t hat eit her has t he answer or has a reference of who m ight have t he answer. Querying nam e servers for t he I P of www.sans.org is an it erat ive process t hat yields a reference of anot her DNS server t hat m ight have t he answer. This process repeat s unt il cont act ing a nam e server t hat has t he I P address answer. Because h.root - servers referred dns.m y.com t o anot her DNS server, in t he t hird line of t he preceding out put , you see dns.m y.com query t his server,

server1.sans.org, for t he I P for www.sans.org. server1.sans.org happens t o " own" t he DNS record for www.sans.org and can ret urn t he I P address associat ed wit h www.sans.org t o dns.m y.com . At long last , dns.m y.com delivers t he response t o host .m y.com . TCPdum p has a unique form at t hat cont ains necessary insight int o what is happening bet ween DNS connect ions. Look at t he next sect ion t o help you decipher t he TCPdum p out put . St r a n ge TCPdu m p N ot a t ion

Look at t he exchange bet ween dns.m y.com and h.root - servers.net t hat follows:

dns.my.com.53 > h.root-servers.net.53: 12420 (30) (DF) h.root-servers.net.53 > dns.my.com.53: 12420- 0/3/3 (153) (DF)

The first line of TCPdum p out put is t he query from dns.m y.com t o t he root server. The first field t hat you have not seen before in convent ional TCPdum p out put is t he num ber 12420, following t he colon aft er dest inat ion port 53. This is t he DNS ident ificat ion num ber. I t is a unique ident ifying num ber t hat a DNS server or client uses t o m at ch a query and response. dns.m y.com issues t he request t o t he root server wit h t he num ber 12420, and when it receives a response, it can pair it t o t he request . You have t o be aware t hat a busy dns.m y.com is probably doing a lot of ot her queries while it is doing yours, so it has t o be able t o m at ch m ult iple queries wit h responses. The lengt h of t he UDP payload ( not including t he I P or UDP headers) is 30 byt es. And, t he Don't Fragm ent ( DF) flag is set so t hat t his dat agram won't be fragm ent ed. The response t o query 12420 follows. A dash aft er 12420 signifies t hat recursion was not desired. This m eans t hat dns.m y.com t old t he root server t hat it want ed a response t hat referenced where t he next DNS server is—it did not want t he root server t o pursue finding t he response it self. Root servers are very busy com put ers, processing m any init ial DNS request s, and t hey cannot process queries in a recursive fashion like dns.m y.com can. Root servers are only expect ed t o give what ever knowledge t hey have about a good reference in pursuit of t he answer. I f you were hopelessly lost in a cit y som ewhere and cam e across a policem an direct ing t raffic at a busy int ersect ion, you would know bet t er t han t o ask him direct ions t o Aunt Sadie's place. I f you had t he poor sense t o ask, t he best you could hope for is a general hast y reference t o a gas st at ion t hat could give you bet t er direct ions. I n t he response from t he root server, you see som e st range out put in t he form at of 0/ 3/ 3. This says t hat t here were zero answer records, m eaning no I P address was found, but t hree aut horit y records were found and t hree addit ional records

were found. An aut horit at ive server is one t hat " owns" and m aint ains records for a given dom ain. You don't see t his in t he TCPdum p out put , but t he t hree aut horit at ive servers ( server1.sans.org, ns.BSDI .COM, and ns.DELOS.com ) and t he t hree addit ional records are shown wit h t he pairing of t he aut horit at ive DNS servers wit h t heir I P addresses. AUTHORI TY RECORDS

sans.org

nam eserver = server1.sans.org

sans.org

nam eserver = ns.BSDI .COM

sans.org

nam eserver = ns.DELOS.COM

ADDI TI ONAL RECORDS

server1.sans.org

I nt ernet address = 167.216.198.40

ns.BSDI .COM

I nt ernet address = 206.196.44.241

ns.DELOS.COM

I nt ernet address = 65.102.83.117

The sect ion, " Using DNS for Reconnaissance," shows you how t o use t he nslookup com m and t o discover t his inform at ion. By sending t he I P addresses in addit ional records, when using t he ret urned aut horit at ive nam e servers, subsequent resolut ions are unnecessary t o t ranslat e t hose ret urned host nam es t o I P addresses. Any one of t hose DNS servers has aut horit y for t he sans.org dom ain and can answer t he query. As you saw, dns.m y.com select s t he first one, server1.sans.org, t o use for t he final resolut ion. Finally, exam ine t he rem ainder of t he TCPdum p out put from t he resolut ion process:

dns.my.com.53 > server1.sans.org.53: 12421+ (30) (DF) server1.sans.org.53 > dns.my.com.53: 12421* 1/3/3 (172) dns.my.com.53 > host.my.com.1716: 1* 1/3/3 (197) (DF)

dns.m y.com has been inform ed t hat t here are several aut horit at ive servers, and it select s t he first one, server1.sans.org, for resolut ion. I t issues a new query 12421 and asks for recursion, not ed by t he plus sign. Essent ially, dns.m y.com has t asked server1.sans.org t o find t he I P address. I n t his case, server1.sans.org is an aut horit at ive nam e server for www.sans.org, so it can answer t he query it self. I f it were not t he aut horit at ive nam e server, however, it would be asked t o find t he I P address by recursively issuing queries t o ot her nam e servers unt il an I P address

was found. Not all DNS servers are configured t o perform recursive queries; so even t hough recursion m ight be desired, it is not necessarily done. server1.sans.org responds t o t he query. The ast erisk m eans t hat t his is an aut horit at ive response. This says t hat t he record for www.sans.org is in t he DNS dat abase t hat server1.sans.org m aint ains. One answer is ret urned—in t his case, t he I P address of www.sans.org, 12.33.247.6. You do not see t he I P in t he TCPdum p out put , but t hat is what is in t he payload of t he UDP dat agram . The t hree aut horit y records and t hree addit ional records t hat were previously discussed are ret urned here t oo. Last ly, aft er dns.m y.com has t he I P address, it ret urns it t o host .m y.com , t he original querier. Ca ch in g: Be e n The r e , D on e Th a t This sect ion briefly explains what happens t o received responses. DNS servers cache or save responses t hat t hey receive. This m akes t he resolut ion process m ore efficient if t he sam e DNS queries do not have t o be repeat ed over and over again. This also pot ent ially reduces t he num ber of hit s t hat ot her DNS servers t ake responding t o queries. Chances are pret t y good t hat t he sam e host nam e t o I P resolut ion t hat was request ed once m ay be request ed again soon t hereaft er. But , as you will soon see in t he sect ion, " Cache Poisoning," t hese savings, gained by caching responses, will open up som e securit y risks if cached responses are not aut hent ic and valid. I f you were t o ask for t he www.sans.org web page again soon aft er t he first request , t he resolut ion process would differ a lit t le. Your host st ill issues a get host bynam e call t o resolve t he I P address for www.sans.org. When dns.m y.com receives t his request , however, it checks it s cache as usual before t rying t o resolve it . I f everyt hing is working correct ly, dns.m y.com finds t he record residing in cache and ret urns t he I P address t o host .m y.com . How long do cached records st ay around on t he DNS server? Well, it depends. Each cached record m ight have a different life span. I t t urns out t hat each response of a DNS resource record has a DNS t im e- t o- live ( TTL) value. Don't confuse t his TTL value wit h t he I P header TTL. They represent t wo very different and dist inct funct ions. The DNS TTL value is set by t he responding DNS server and cached by t he receiving nam e server for t he TTL t im e value. DNS servers t hat updat e records oft en are m ore likely t o have lower TTL values t han relat ively st at ic servers have.

Be r k e le y I n t e r n e t N a m e D a e m on Berkeley I nt ernet Nam e Daem on ( BI ND) is t he de fact o st andard DNS im plem ent at ion in use on t he I nt ernet t oday. Older versions of BI ND are 4.x.x, whereas t he m ore current versions are 8.x.x and 9.x.x. When you observe DNS servers t hat com m unicat e wit h bot h source and dest inat ion

port s of 53, it is usually indicat ive of t he default behavior of BI ND 4.x.x. By default , BI ND versions 8 and lat er assign an ephem eral source port great er t han 1023 in a querying DNS server dat agram , sim ilar t o t he behavior t hat you wit nessed wit h ot her client applicat ions, such as t elnet . However, BI ND versions 8 and lat er can be configured t o m im ic version 4 behavior by using a default source port of 53. This is done using t he query- source address * port 53 configurat ion file subst at em ent . Som e sit es find t hat t his configurat ion bet t er suit s exist ing firewall/ rout er access rules. Re ve r se Look u ps Occasionally, you will be given an I P address and want t o see whet her it resolves t o a host nam e. This is done via a get host byaddr call by t he client resolver. Rem em ber, DNS is a dist ribut ed hierarchy of responsibilit y, and resolut ion begins at t he root node and cont inues down in t he DNS t ree.You saw t op- level dom ain nodes, such as .org, .m il, .edu, and so fort h. A special dom ain has been reserved for resolut ion of I P addresses t o host nam es. At t he t op- level dom ain, t his is t he arpa suffix. A second- level dom ain follows, known as in- addr. The t ree expands out ward beneat h t his for t he legal first oct et s in t he I P address, as you see in Figure 6.5. I n t he case of t he I P for www.sans.org, for inst ance, t he first oct et is 12. Beneat h t his follows a subt ree wit h t he next node of 33, t he second oct et of t he www.sans.org I P address. Cont inuing wit h t his logic, t he 247 and 6 nodes for t he final t wo oct et s fall below. Only t his subt ree is exam ined in t his exam ple, but t his subt ree spans all t he possible I P addresses j ust as t he ot her t op- level dom ains begin t he expansion of all t he host nam es. Figu r e 6 .5 . Re ve r se look u ps, I P a ddr e ss t o h ost n a m e .

Resolut ions of I P t o host nam e are known as reverse lookups. When DNS at t em pt s a reverse lookup for 12.33.247.6, t he applicat ion soft ware reform at s t his as a query t o 6.247.33.12.in- addr.arpa. The order of t he oct et s is reversed t o conform t o t he host nam e not at ion. For nam e www.sans.org, t he nam e is form ulat ed by st art ing at t he bot t om of t he DNS t ree wit h node www, m oving up t o node sans, and t opping out at node org. Sim ilarly, wit h t he I P address, you m ust m ove from t he m ost specific t o t he m ost general. M a st e r a n d Sla ve N a m e Se r ve r s Each dom ain m ust have a m ast er server, upon which dat abase records of nam es and I P addresses are m aint ained. Then, for redundancy sake, one or m ore slave servers are oft en creat ed in case t he m ast er server ever goes down. I f t here is no redundancy built in and t he only DNS server for a part icular dom ain were t o go down, no queries could be answered for host s in t hat dom ain. Unless ent ries were cached at ot her DNS sit es, resolut ion of host s in t he dom ain whose DNS server was down could not be accom plished. Slave servers can share t he load of responding t o queries wit h a fully funct ioning m ast er nam e server. DNS inform at ion is m aint ained on t he m ast er server in flat t ext files. The slave nam e servers periodically cont act t he m ast er nam e server t o see whet her any updat es have been m ade for a part icular dom ain. I f so, t he slave servers wit h older versions of BI ND download all inform at ion for t hat dom ain, even if only one record has been m odified. Newer versions of BI ND will allow increm ent al updat es t hat will download only changed records. Zon e Tr a n sfe r s This sect ion exam ines how changes are propagat ed from t he m ast er t o t he slave nam e server. When t he slave server rest art s, or when it periodically queries t he m ast er server and finds updat ed records, a zone t ransfer is perform ed bet ween t he m ast er and slave servers. This is j ust a t ransfer of t he zone m aps or DNS records from t he m ast er server t o t he slave server. Unlike m ost DNS t ransact ions, t his is done using TCP because t here is pot ent ially a lot of dat a and reliable delivery is im port ant . The zone t ransfer seem s like an innocuous process. I t usually is bet ween t he sam e dom ain m ast er and slave servers. Yet , what if a hacker could do a zone t ransfer of your dom ain dat a for your int ernal host s? This would give him all t he I P addresses and host s in your dom ain. This is very valuable dat a t hat should not be readily available t o anyone. Obviously, you would like t o t ry t o prevent t his kind of m isuse. You can do t his in a couple of ways. I n versions of BI ND 4.9.3 and lat er, configurat ion param et ers enable t he DNS adm inist rat or t o specify I P addresses or subnet s aut horized t o do zone t ransfers. BI ND 4.9.x has an xfernet s direct ive, and BI ND 8 and 9 have an allow- t ransfer subst at em ent t o cont rol zone t ransfers.

I f your version of BI ND does not support t his feat ure, anot her opt ion is t o block inbound t raffic t o TCP port 53. This block prevent s t ransfers, but m ight block ot her legit im at e dat a as well ( as discussed in t he very next sect ion) . I f t his is your only opt ion, however, it is preferable t o prevent t he zone t ransfer, even at t he expense of blocking ot her legit im at e dat a. UD P or TCP As discussed earlier, t ypically, DNS t raffic is sent using UDP because answers are oft en succinct , and a best - delivery effort can be t olerat ed because responses t o DNS queries not received can be reissued. Because t here is m ore dat a for zone t ransfers, and reliable exchange is required, t hey are an except ion t o t he UDP prot ocol and are done using TCP. The m axim um allowable size for a UDP DNS payload response is 512 byt es. What happens if t he dat a cont ained in t he DNS m essage exceeds 512 byt es? First , t he response is ret urned wit h t he t runcat ed bit t urned on. This bit is found in t he flags field spanning offset byt es 2 and 3 of t he DNS m essage:

dns.my.com.53 > dns.verbose.com.53: 18033 (43) (DF) dns.verbose.com.53 > dns.my.com.53: 18033| 7/0/0 (494) dns.my.com.37404 > dns.verbose.com.53: S 518696698:518696698(0) win 8760 (DF) dns.verbose.com.53 > dns.my.com.37404: S 199578733:199578733(0) ack 518696699 win 8760 (DF)

I n t he preceding out put , look carefully at t he second line of TCPdum p out put . The response is from dns.verbose.com t o dns.m y.com . Aft er t he DNS ident ificat ion num ber, 18033, you see a vert ical line, or UNI X pipe sym bol. This is t he not at ion t hat TCPdum p uses t o alert you t hat t he DNS record has been t runcat ed. The response of seven resource records would have exceeded t he 512- byt e payload lim it . You see t hat 494 byt es of payload are ret urned, consist ing of com plet e answers t hat do not exceed t he lim it . Therefore, dns.m y. com reissues t he DNS query using TCP. You see t he at t em pt ed SYN connect ion from dns.m y.com t o dns.verbose.com . dns.verbose.com responds wit h a SYN/ ACK, indicat ing t hat it is list ening on port 53. The inform at ion is t hen t ransferred using TCP as t he prot ocol. Som e sit es will block all inbound TCP t raffic wit h eit her a source or dest inat ion port of 53 t o prevent unaut horized zone t ransfers. But , t his will also block any queried ext ernal DNS server from resolving large responses. That is what happens in t he preceding out put . The fourt h line in t he previous out put shows t he packet wit h t he SYN/ ACK from dns.verbose.com t hat got blocked. Our packet - filt ering device in front of dns.m y.com blocks a TCP connect ion from dns.verbose.com source port dom ain ( 53) . That is why t he t hree- way handshake is never com plet ed and t he

large DNS response is never delivered. To avoid t his problem , block t raffic t o TCP dest inat ion port 53 only and allow t raffic from TCP source port 53 t hat has an already est ablished connect ion. Su m m a r y of D N S Th e or y DNS relies on a com plex int erweaving of m any DNS servers.You m ust be able t o exam ine t raffic t o and from your DNS server t o underst and t he nat ure of t he act ivit y. TCPdum p is an adequat e t ool t o use; but at t im es, you have t o use ot her t ools t o exam ine t he cont ent of t he dat agram s t o see whet her problem s exist . Typical DNS servers on act ive net works receive a lot of t raffic, and hackers can use t he volum e of norm al act ivit y as a sm oke screen for m alicious act ivit y.

Usin g D N S for Re con n a issa n ce Given t he not ion t hat DNS is a global dat abase, it is an excellent source for reconnaissance. DNS inform at ion is int ended t o be freely shared and freely available in t he spirit of cooperat ion. At one t im e in t he evolut ion of t he I nt ernet , t his was a relat ively innocuous philosophy. I n t oday's clim at e of hungry pirat es, however, it seem s quit e naive. Here are som e ways in which reconnaissance can be done using DNS. Th e n slook up Com m a nd nslookup act s m uch like a DNS client would, but displays t he inform at ion so t hat you can see it . I n fact , t hat is how t he aut horit at ive nam e server host nam es and I P addresses for t he sans.org dom ain were obt ained. This is a very helpful int eract ive t ool t hat can be used on a UNI X or Windows NT ( and beyond) host . Som e UNI X operat ing syst em s are beginning t o replace t he nslookup com m and wit h t he dig ( Dom ain I nt ernet Groper) com m and. You can ask m any m ore quest ions of a DNS server t han j ust t he host nam e. Using nslookup, you can form ulat e queries and see t he kinds of responses you get . There is also a debug set t ing t hat enables you t o see m ore of t he dat a in t he DNS m essage t hat is sent and ret urned t han j ust t he query and response values. Look at t he following out put t o get an idea of t he capabilit ies of t he nslookup t ool. You see host .m y.com issue t he nslookup com m and. You t hen ent er int o t he nslookup int eract ive process and receive not ificat ion of t he default DNS server, dns.m y.com and it s associat ed I P address ( 192.168.4.4) used t o resolve your queries. The out put follows:

host.my.com% nslookup Default Server: dns.my.com Address: 192.168.4.4

> www.sans.org Server: dns.my.com Address: 192.168.4.4 Name: www.sans.org Address: 12.33.247.6

At t he great er t han ( >) prom pt , www.sans.org is ent ered t o find it s I P address. Again, you get confirm at ion of t he DNS server and I P address being used t o resolve t he query. You see t he answer below t hat of 12.33.247.6. N a m e Th a t N a m e Se r ve r

How does som eone discover what your DNS server is? Given t he num ber of reconnaissance at t em pt s t arget ing DNS servers only, t here m ust be a way t o find out . Act ually, it is rat her easy t o find t his out using nslookup:

> set type=ns > sans.org Server: dns.my.com Address: 192.168.4.4

NON- AUTHORI TATI VE ANSWER sans.org nam eserver = NS.DELOS.COM sans.org nam eserver = server1.sans.org sans.org nam eserver = NS.BSDI .COM AUTHORI TATI VE ANSWERS CAN BE FOUND FROM NS.DELOS.COM I nt ernet address = 65.102.83.117 server1.sans.org I nt ernet address = 167.216.198.40 NS.BSDI .COM I nt ernet address = 206.196.44.241 Assum ing t hat you are at a subcom m and prom pt of t he nslookup com m and, ent er t he subcom m and set t ype= ns. You have j ust set t he opt ion t o ret urn an answer of a nam e server( s) t o subsequent queries issued. Bum p up one node on t he DNS t ree and query for sans.org t o see t he nam e servers for t his dom ain. You discover all t he nam e servers for sans.org, bot h host nam es and I P addresses. This appears t o be a pret t y good place t o st art t he reconnaissance effort for a sit e. Aft er discovering t he nam e servers, one m ight scan t hose nam e servers for pot ent ial securit y deficiencies or t o see what kind of I nt ernet services or daem ons are being run on t he DNS server.

H I N FO: Sn oopin g for D e t a ils HI NFO records are yet anot her record t ype st ored by DNS. These are inform at ion records and anot her pot ent ial source for reconnaissance. A DNS server adm inist rat or has t he opt ion of ent ering host inform at ion, specifically t he CPU t ype and operat ing syst em , when creat ing a new or m aint aining an exist ing DNS record. I f t rust ed int ranet host s use t he DNS server, t his is a way t o m aint ain an invent ory of t he host s wit hout t oo m uch risk. Because t his provides t oo m uch inform at ion t o unknow n I nt ernet users, m any adm inist rat ors do not ent er t hese param et ers. Obviously, if t his t ype of inform at ion can be harvest ed from a DNS server, a hacker can get som e serious int elligence about t he sit e.

> set type=hinfo > host49 Server: dns.my.com Address: 192.68.4.4 host49.my.com CPU = SunSparc OS = Solaris my.com nameserver =dns.my.com dns.my.com Internet address = 192.68.4.4

Set t he t ype t o hinfo as a subcom m and in nslookup. I nform at ion is queried for host 49, which is a fict ional renam ing of a real host . host 49.m y.com is a Sun SPARC running a version of t he Solaris operat ing syst em . I t is possible t hat a hacker's effort s m ight be foiled by out dat ed dat a kept in t he HI NFO records. This is probably one of t he few t im es t hat less- t han diligent m aint enance is a desirable t hing. List Zon e M a p I n for m a t ion One of t he easiest ways t o discover a lot of inform at ion about a dom ain is t o t ry t o list all t he zone m ap inform at ion. Assum e t hat t here is a dom ain wit h t he lacklust er nam e of fakeplace.com . You can at t em pt t o dum p t he records associat ed wit h t he dom ain using t he following subcom m and in t he nslookup ut ilit y:

> ls –d fakeplace.com

I f t he sit e has not disabled t he dissem inat ion or t ransfer of t he dat a, t he DNS server list s all records for t he dom ain fakeplace.com . As a bonus t o t he inform at ion collect or, t his sit e also m aint ains HI NFO records.

whish 1D IN A susie 1D IN A pixie 1D IN A bandit 1D IN A adder 1D IN A hub21 1D IN A switch3 1D IN A

1D IN HINFO 1D IN HINFO 1D IN HINFO 1D IN HINFO 1D IN HINFO 1D IN HINFO 1D IN HINFO

"SGI" "Irix" 192.168.1.239 "IBM-RS/560F" "unix" 172.16.16.13 "IBM-RS/560F" "unix" 172.12.16.14 "PC" "Win98" 192.168.3.107 "IBM-RS/530" "unix" 172.16.133.4 "Cabletron-MMAC3" "SNMP" 192.168.26.80 "Switch" "3COM" 192.168.7.130

This inform at ion harvest ing can occur only if t he sit e allows indiscrim at e access t o TCP dest inat ion port 53, because TCP is t he t ransport prot ocol used t o deliver t his inform at ion. D ig Anot her inform at ion gat hering t echnique is t o query a DNS server for it s BI ND version num ber:

dns.my.com% dig @MYDNS.COM version.bind txt chaos ; dig 8.1 @MYDNS.COM version.bind txt chaos ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER t o easily ident ify t he part of t he record we will scrut inize. DNS quest ions have a prescribed form at . A DNS quest ion has a series of nodes t hat end in a 00 t o form t he quest ion. We t ypically see nodes t hat are separat ed by periods when we express a host nam e or I P address. For inst ance, if an I P address resolut ion were desired for www.yahoo.com, t he DNS quest ion t hat would be generat ed would t reat t he nam e as a series of nodes—www, yahoo, and com . Preceding each node is a byt e count t hat t ells how m any byt es are in t he following node. The version.bind quest ion t hat was generat ed using sidest ep's norm al opt ion is as follows:

0776 6572 7369 6f6e 0462 696e 6400

The bolded byt es represent labels. The first label is 07, which m eans t hat t here should be 7 byt es in t he first node of t he query. I n t his inst ance, t he hex charact ers t hat follow are t he ASCI I represent at ion of t he node " version" . Next , you see a label of 04 m eaning t hat t here are 4 byt es in t he following node, which

is t he hex represent at ion of t he ASCI I " bind" . A 00 label ends t he query, which is t he final label t hat is seen. Each quest ion requires a DNS t ype and class, each of which is a 2- byt e field. The various different t ypes and classes can be found in RFC 1035, but for t he purposes of t he BI ND version query, t hese m ust be a t ype of TXT represent ed by a 16 ( or hex 0010) and a class of CHAOS represent ed as a 3 ( or hex 0003) . An accessible DNS server t hat does not prevent version.bind queries will respond t o t he above query wit h t he version of BI ND t hat is running. Eva sive Qu e r y Let 's exam ine t he out put t hat was generat ed by TCPdum p displayed in hexadecim al t o underst and t he evasive act ivit y:

12:39:56.674320 10.100.100.201.1129 > DNS.SERVER.domain: 4500 0a64 0001 c01a

003c 6402 0000 0010

0577 0469 0000 0003

| | V Pointer 26 bytes into DNS Payload

0000 0035 0000 0442

8011 0028 0756 494e

c009 0a64 64c9 e445 | | V 26 Bytes

42 (32)

E.. on t he left side of t he out put . Moving 26 byt es int o t he DNS m essage direct s us t o t he st ring beginning wit h 0442 494e 4400. The 04 is t he label 26 byt es int o t he DNS m essage, and as expect ed, it is followed by 4 byt es t hat represent t he st ring " BI ND" . The query t hen ends when a label of 00 is encount ered. I t appears t hat resolut ion of t he

query resum es at t he next byt e aft er t he first point er in t he query nam e. This brings us back t o t he st ring " 0010 0003" t hat represent s t he query t ype of TXT and a query class of CHAOS. This query elicit s t he version of BI ND running on t he queried DNS server if t he DNS server does not prevent queries for t he version of BI ND. Sidest ep can be found at www.robert graham .com / t m p/ sidest ep.ht m l.

I n t r odu ct ion t o Pa ck e t D isse ct ion Usin g TCPdu m p When you run TCPdum p in st andard m ode, it will dum p t he m ost pert inent fields in t he packet . More fields will be collect ed t han displayed in t he default 68 byt es of capt ure ( 14 byt es for Et hernet fram e header and t he rem ainder for t he I P packet ) . Yet , all of t he fields will not be displayed unless you ask for TCPdum p t o display t he out put in hexadecim al m ode using t he –x com m and line opt ion. The first t hing t hat you have t o do before at t em pt ing any kind of packet dissect ion is arm yourself wit h t he st andard layout s of t he various kinds of TCP/ I P headers such as I P, TCP, UDP, and I CMP. There are m any sources of t hese including t he RFCs. Look at t he following out put t o see a sam ple of hexadecim al out put from TCPdum p using t he –x com m and line opt ion:

11:55:52.069484 192.168.143.5 > 192.168.143.101: icmp: echo request 4500 c0a8 510f 1415

0054 8f65 0100 1617

064b 0000 4001 bc12 c0a8 8f05 0800 620a 850a 0000 889f 4b39 0809 0a0b 0c0d 0e0f 1011 1213 1819

I t looks like a big j um ble of garbage at first glance. Let 's begin m et hodically t o describe t he out put . First , each charact er you see is a hexadecim al charact er, as you m ight have ast ut ely int uit ed from t he fact t hat we are doing hex out put . ( Okay, enough sarcasm .) Each hex charact er can have a value of 0 t o 0xf, which corresponds t o 0 t o 15 decim al. Again, t he 0x not at ion m eans hexadeci- m al. And, each hex charact er is 4 bit s, also known as a nibble. That m eans t wo hex charact ers are 8 bit s or one byt e. Finally, each row of hex dum ped by TCPdum p has 16 byt es or 32 hex charact ers. The t rick is " superim posing" t his hex out put over a st andard layout of t he fields. I n t his case, we are looking at an I P header followed by som e em bedded prot ocol t hat we will discover as we progress. Take a look at Figure 7.1. I t shows t he st andard I P header layout t hat we've exam ined several t im es before in t he book. Let 's j ust m ake sure we can look at a field or t wo before we m ove on. For inst ance, t he first field you see in t he I P header layout is t he I P version num ber, which is 4 bit s long. I f we look at t he previous hex dum p, we see t hat t he first hex charact er is a 4. This is t he I P version num ber or I P version 4.

Figu r e 7 .1 . I P h e a de r la you t .

That was fairly sim ple. Let 's t ry som et hing a lit t le m ore advanced. Anot her very im port ant field is t he prot ocol field found in t he I P header. This t ells us t he em bedded prot ocol t hat follows t he I P header. I f you look at Figure 7.1, you'll see t hat t he 8- bit prot ocol field is found in t he t hird row of t he I P header. This layout is different from t he hex dum p because each row cont ains 32 bit s of out put or 4 byt es. No m at t er, we can st ill find t he displacem ent of t he prot ocol field from t he beginning of t he I P header ( again, anot her annoying rem inder t hat we st art count ing at offset 0) . So, each row cont ains 4 byt es, and we find t he prot ocol is locat ed in t he 9 t h byt e offset of t he I P header. The 9 t h byt e offset found in t he hex dum p is 01. A value of 01 in t his field m eans t hat t he I CMP prot ocol follows t he I P header. Ot her com m on values t hat we will exam ine are a value of 06 m eans TCP follows, and a hex 11 or decim al 17 m eans t hat UDP follows t he I P header.

W h e r e D oe s t h e I P St op a n d t h e Em be dde d Pr ot ocol Be gin ? We j ust learned how t o det erm ine what em bedded prot ocol follows t he I P header— a very significant st ep in doing packet dissect ion. The next problem we encount er is knowing where headers st op and ot her part s of t he packet begin. A norm al I P header wit h no I P opt ions such as source rout ing has a lengt h of 20 byt es. An I P header great er t han 20 byt es long should cont ain I P opt ions. The I P header lengt h is found in t he 0 byt e offset of t he I P header in t he low- order nibble. This is t he hex charact er t hat follows t he I P version num ber. But , we find a value of 5 t here. How does t hat relat e t o a norm al 20- byt e header? The I P header lengt h is expressed in 32- bit words, m eaning t hat any value found in t his field m ust be m ult iplied by 4. Alt hough it would be nice and a whole lot less com plicat ed if all t he m any lengt hs

fields found in t he packet were expressed in byt es, t his j ust isn't t he case. You m ight be t hinking ( or cursing t o yourself) , why couldn't t he wise creat ors of TCP/ I P have been m ore m erciful and st andardized on byt es? The m ost likely reason is t hat when TCP/ I P was creat ed years ago, hardware and soft ware were m uch slower and it t ook longer t o send m ore dat a, even a couple of bit s. The t hought was t hat if bit s could be com pressed, t hey could be processed or sent m ore quickly. So t here is som e rhym e and reason t o what you m ight perceive as random m ayhem . Now t hat we know t hat we have a 20- byt e I P header, we count 20 byt es int o t he hex dat a t hat we find in previous hex out put . When we deal wit h lengt h byt es, we have a t ot al of 20 byt es. We aren't concerned about offset s, so we don't need t o st art count ing at 0. We sim ply count off a num ber of t ot al byt es, in t his case 20. We have 16 byt es in t he first row of hex out put and need only t o count off 4 m ore in t he second row t o t ake us t o where t he I P header st ops and t he I CMP header begins in t his packet . The I CMP header begins wit h t he first t wo byt es of 0800.

Ot h e r Le n gt h Fie lds Let 's look at som e ot her lengt h fields in t he I P packet . Ult im at ely, we need t o know how t o int erpret t hese values t o be able t o decode t he packet . Th e I P D a t a gr a m Le n gt h Anot her very im port ant field is t he I P packet t ot al lengt h. Fort unat ely, t his is expressed in byt es so we don't have t o m anipulat e it in any way. This field is found in t he second and t hird byt es offset of t he I P header. The only t ricky part is com put ing t his from hex t o decim al.

Con ve r t in g H e x t o D e cim a l Taking hex out put and convert ing it t o decim al m ight not be int uit ive, so we need a review. Any t im e you need t o convert hex t o decim al for a field, do t he following: 1 . Figure out how m any hex charact ers are in t he field by exam ining t he prot ocol layout . 2 . St art at t he right m ost hex charact er. 3 . Represent each hex charact er in t he field as an increasing power of 16 beginning wit h an exponent of 0. 4 . Mult iply each base by exponent and add all individual product s. For inst ance, in t he previous exam ple, we find t he value of 0054 in t he I P

dat agram t ot al lengt h. Going st ep by st ep t o t ranslat e it t o decim al: 1 . The I P dat agram lengt h is 16 bit s. 2 . This is 4 hex charact ers of out put . 3 . St art at t he right m ost hex charact er ( 4) . 4 . Represent each hex charact er as an increasing power of 16 ( 16 0 t hrough 16 3 ) . 5 . Mult iply each base by exponent and add all individual product s.

163 0

162 161 160 0 5 4

5*161 + 4*160 = 84

I n t he previous exam ple, we are looking at t he lengt h field. We have 4 hex charact ers because t he lengt h is a 16- bit field. We really only need t o label t he t wo right m ost hex charact ers because t hey are non- zero. Aft er we do t his, we find we have a 4 in t he 16 0 posit ion; t his is really t he 1's posit ion m eaning we have 4* 1 or 4. The next charact er of 5 is in t he 16 1 posit ion. So, we m ult iply 5* 16 for a product of 80. We add t hese t wo product s t oget her t o get t he final result of 84. TCP H e a de r Le n gt h Like t he I P header, t he TCP header can also have opt ions. Also, like t he I P header lengt h, t he TCP header lengt h is found in a nibble t hat is a represent at ion of 32- bit words. This value, like t he I P header lengt h value, m ust be m ult iplied by 4 t o get t he TCP header lengt h. A TCP header wit h no opt ions is 20 byt es long. The TCP header lengt h is found in t he high- order nibble of t he 12 t h byt e offset of t he TCP header. This is an im port ant value because it det erm ines where t he TCP header st ops and where t he TCP payload begins. Here is st andard out put followed by t he hex out put from a TCP header wit h no TCP opt ions:

15:43:40.705372 1.2.3.4.63220 > 4.3.2.1.139: S 776342897:776342897(0) win 3072 4500 0028 e34f 0000 3a06 e534 0102 0304 0403 0201

The TCP segm ent is delim it ed by t he less t han and great er t han signs. The highlight ed value is t he TCP header lengt h, and as expect ed, we find a 5. Aft er we m ult iply t hat by 4, we get a st andard TCP header of 20 byt es. Now, look at t he hex out put for a TCP header wit h TCP opt ions:

15:48:24.620314 1.2.3.4.3088 > 4.3.2.1:139 S 1212214992:1212214992(0) win 32120 (DF) 4500 0102 a002 0076

003c 0304 7d78 3b6c

11a8 4000 4006 70c8 0102 0304

You see t hat it has a TCP header lengt h of 0xa, which is a decim al 10. This value m ult iplied by 4 indicat es a TCP header lengt h of 40 byt es. I f you look at t he st andard TCPdum p out put before t he hex dum p, you see t hat t his TCP header includes such opt ions as m axim um segm ent size of 1460, select ive acknowledgem ent ( sackOK) , t im est am p, a nop ( no operat ion) t o pad t o a 4- byt e boundary, and a window scale ( wscale) . These opt ions need t o be st ored in t he TCP header.

I n cr e a sin g t h e Sn a ple n Here's a quest ion: Why do you only see 54 byt es of out put in t he following hex out put displayed even t hough t he default num ber of byt es capt ure is 68? Check it out :

4500 c0a8 510f 1415

0054 8f65 0100 1617

064b 0000 4001 bc12 c0a8 8f05 0800 620a 850a 0000 889f 4b39 0809 0a0b 0c0d 0e0f 1011 1213 1819

The answer is t hat TCPdum p capt ures 14 byt es of t he Et hernet fram e header, yet it does not display t hem unless explicit ly direct ed. To display t he capt ured fram e header use t he com m and t cpdum p –e:

20:55:48.520619 0:10:b5:39:c6:93 0:10:b5:39:c6:9a ip 102 192.168.143.5 > 192.168.143.101: icmp: echo request

There will be t im es t hat you will be int erest ed in exam ining t he fram e header. One of t he reasons for t his would be t o ident ify t he source MAC address t o t ry t o

det erm ine where t he packet cam e from —a host or perhaps a rout er. I n t he previous out put , which uses Et hernet encapsulat ion defined by RFC 894, t he bolded t ext is a result of t he –e opt ion. First , you see t he source and dest inat ion MAC addresses ( source MAC of 0: 10: b5: 39: c6: 93 and dest inat ion MAC address of 0: 10: b5: 39: c6: 9a) . You m ight be t hinking t hat t hese are bogus MAC addresses because t hey are so close t oget her, but t hey are genuine MAC addresses. These are t wo Com paq PCs ordered at t he sam e t im e. The MAC addresses are followed by t he t ype of packet t hat follows t he fram e header. Som e of t he t ypes of t raffic you are likely t o see are I P, ARP, and RARP ( reverse ARP) . These fields are all st ored in t he fram e header. The final displayed field is t he lengt h, in byt es, of t he ent ire fram e including t he fram e header and t he dat a in t he encapsulat ed fram e header. I n t his case, it is a fram e header of 14 byt es and a following I P dat agram of 88 byt es t o give 102. A value of 0x0800 in t he t ype field indicat es an I P dat agram follows t he fram e header. The I P packet m ust be at least 46 byt es in lengt h and t he fram e lengt h inform at ion is not cont ained anywhere in t he Et hernet RFC 894 fram e header. The snapshot lengt h, or snaplen for short , is t he num ber of byt es t hat TCPdum p collect s. The default snaplen of 68 byt es is usually enough t o capt ure t he I P header, em bedded prot ocol header, and som e dat a. But , if t here are m any opt ions, eit her I P header opt ions or TCP opt ions, all of t he headers m ight not be capt ured. I f you want t o increase t he default snaplen, use t he –s TCPdum p com m and line opt ion. As a t est case, let 's say we want t o capt ure t he ent ire dat agram for each record we read or process on an Et hernet net work. I n t his case, we need t o increase t he snaplen t o t he m axim um size of t he dat agram plus t he fram e header. Et hernet has a m axim um t ransm ission unit of 1500. I f you add 14 byt es for t he fram e header, t he snaplen m ust be 1514 byt es—t cpdum p –s 1514. Now, t o check if we've collect ed t he ent ire dat agram , we run TCPdum p wit h a snaplen of 1514:

4500 0054 064b 0000 4001 bc12 c0a8 8f05 c0a8 8f65 0800 620a 850a 0000 889f 4b39 510f 0100 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637

I f we dum p t he collect ed record in hexadecim al, we find we've collect ed m ore t han t he default 54 byt es. The act ual dat agram lengt h is found in t he 2 nd and 3 rd byt es offset of t he I P header. We discover a hex 54 in t his field, which we recent ly com put ed is a decim al 84 byt es. And, we see t hat we've collect ed all 84 byt es.

D isse ct in g t h e W h ole Pa ck e t

We have covered all t he fundam ent als required t o dissect a packet . Okay, get t he scalpel out and let 's see if we can at t em pt a couple of I P packet dissect ions. Here's a short review of what we need t o do t o accom plish our dissect ion: z

I dent ify t he em bedded prot ocol in t he packet . This is found in t he 9 t h byt e offset of t he I P header.

z

Det erm ine what t he em bedded prot ocol is based on t he value found.

z

I dent ify where t he header( s) st op( s) , and exam ine t he I P header lengt h. {

z

Tells where t he I P header st ops and t he em bedded prot ocol begins.

Exam ine t he em bedded prot ocol header lengt h {

Tells where t he em bedded prot ocol payload begins.

One of t he first st eps in discovering what t ype of act ivit y is em bedded in t he dat agram is t o discern t he em bedded prot ocol. Rem em ber, you have an I P header and you will find t he em bedded prot ocol in t he 9 t h byt e offset int o t he I P header. Rem em ber t hat t he m ost com m on values you will see here are 01 for an em bedded I CMP m essage, 06 for an em bedded TCP segm ent , and a hex 11 or decim al 17 for an em bedded UDP dat agram . Aft er you've discovered t his, you need t o know how m any byt es are in t he I P header. Usually, t his is 20 byt es, but it can be m ore if t here are I P opt ions. The I P header lengt h field is found in t he low- order nibble of t he 0 byt e offset of t he I P header. Rem em ber t hat t his is expressed as a 32- bit word, so t his value has t o be m ult iplied by 4 t o t ranslat e t o byt es. I f you count off t his num ber of byt es int o t he I P header, you will discover where t he I P header st ops and t he em bedded prot ocol begins. Next , you need t o exam ine t he em bedded prot ocol. You'll have t o get t he proper header configurat ion for t he prot ocol and t ranslat e t he values t hat you find in t he hexadecim al out put . For UDP, t he header lengt h rem ains st at ic at 8 and t he payload follows. But , a header has a different form at depending if t he prot ocol is I CMP, TCP, or UDP. TCP header lengt hs can vary, so you'll have t o find t he TCP header lengt h field. This is 12 byt es offset int o t he TCP header, specifically, t he high- order nibble. Again, like t he I P header lengt h, t his is expressed as a 32- bit word and t he value will have t o be m ult iplied by 4 t o convert it t o byt es. This inform s you where t he TCP header st ops and t he payload st art s. Here is t he hex dum p of our specim en for dissect ion:

4500 0054 f23b 4000 ff01 d121 0102 0304 0403 0201 0000 9f00 d646 0000 b4cb 863a 56af 0e00 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 0000 4e00

Let 's approach t his in t wo different part s. I n t he first part , we'll at t em pt t o discover t he em bedded prot ocol and t he lengt h of t he I P header. We see t hat t he em bedded prot ocol is I CMP because we have a 0x01 value ( bolded) in t he prot ocol field 9 byt es offset int o t he I P header. That indicat es t hat an I CMP echo reply m essage follows t he I P header ( last 2 byt es of 0201) . Because t he I P header is 20 byt es, we discover where t he I P header st ops and t he I CMP header and dat a begin. The I CMP header begins at t he 2 byt es 0000 following t he final 2 byt es of t he I P header. I n our second st ep of dissect ion, we need t o exam ine t he I CMP m essage header. Rem em ber t hat each individual charact er you see in t he hex out put represent s a nibble or 4 bit s. So, t wo hex charact ers are one byt e. Use Figure 7.2 t o assist in decoding t he I CMP m essage. Figu r e 7 .2 . I CM P h e a de r la you t .

When exam ining I CMP, t he I CMP header form at can vary depending on t he I CMP m essage t ype and code. The first t wo byt es of t he I CMP header are really pert inent when t rying t o assess what t ype of I CMP m essage you have. These are t he m essage t ype and m essage code fields. There are m any possible different values for t hese fields t hat can be found at

www.iana.org/ assignm ent s/ icm p- prot ocols; however, we see a very com m on one in t he above record. An I CMP m essage wit h a t ype of 00 and a code of 00 is an I CMP echo reply. The st andard TCPdum p out put for t his out put is as follows:

1.2.3.4 > 4.3.2.1: icmp: echo reply (DF)

Let 's t ry one m ore exercise in packet dissect ion:

4500 0030 df3c 4000 8006 633f 0102 0304 0403 0201 0b64 0015 48f3 05b1 0000 0000 7002 2000 50b6 0000 0204 05b4 0101 0402

This is a different prot ocol t han I CMP. What is of m ost int erest is t he em bedded prot ocol dest inat ion port . This t ells you t he purpose of t his part icular packet . Alt hough t he TCP and UDP headers are different , t hey share a sim ilar charact erist ic of having t he source port in byt es 0 and 1 offset of t he em bedded header and t he dest inat ion port in byt es 2 and 3 offset of t he em bedded header. Once again, we find an I P dat agram wit h a 20- byt e I P header. But , t his t im e we find t hat we have TCP as t he em bedded prot ocol as ascert ained by looking at t he bolded prot ocol field in t he previous hex dum p. The significant piece of inform at ion t hat helps us assess t he funct ion of t he TCP segm ent is t he dest inat ion port . This is found in t he bolded value of 0015 posit ioned in offset byt es 2 and 3 of t he TCP header. We det erm ine t hat t he decim al t ranslat ion is port 21, which is ft p. The dest inat ion port field has a hexadecim al value of 0015. To t ranslat e t his t o decim al, we find a 1 in t he 16 1 posit ion and a 5 in t he 16 0 posit ion. When t hese 2 values are added, we have 16 + 5, which gives us dest inat ion port 21. So, we have som e kind of ft p exchange. This is t he beginning of t he 3- way handshake so we have no payload.Yet , it helps t o look at t he TCP header lengt h found in t he high- order nibble of t he 12 t h byt e offset of t he TCP header. A value of 7 is found here and t his m ust be m ult iplied by 4 t o figure out t hat t here is a 28byt e TCP header. This m eans t hat t here are TCP opt ions; and exam ining t he following st andard out put of TCPdum p for t he dat agram , we see t hat t here are opt ions of m axim um segm ent size ( m ss) , t wo nops t o pad 4- byt e boundaries, and a select ive acknowledgem ent ( sackOK) :

18:26:48.888088 1.2.3.4.2916 > 4.3.2.1.21: S 1223886257:1223886257(0) win 8192 (DF)

Fr e e w a r e Tools for Pa ck e t D isse ct ion Now t hat you've m anually labored your way t hrough packet dissect ion, here are som e excellent t ools t o help you out . Just t o rem ind you of why we st ruggled wit h our own packet dissect ions at all, you will som et im es find packet s t hat have been craft ed and t hat are not analyzed accurat ely by t ools whose int erpret at ions rely on properly configured packet s. Et h e r e a l Et hereal is free, available for bot h Windows and UNI X, and is part icularly userfriendly because it has a GUI t o assist in navigat ing t he capt ure and analysis. Et hereal can read TCPdum p binary out put capt ured using t he –w opt ion. I t can also use TCPdum p filt ers t o select ively capt ure or display records. Et hereal is an especially useful t ool because it allows you t o analyze a capt ured record from m any different perspect ives. Figure 7.3 shows a snapshot of Et hereal out put . I n t he t op screen, you see a highlight ed record. I f you m ove t o t he m iddle screen, you can view t he fram e header, t he I P header, and t he TCP header, including m ore inform at ion about m any of t he fields. Also, Et hereal is prot ocol- aware for m any prot ocols and at t em pt s t o int erpret t he payload according t o RFC and prot ocol specs. Figu r e 7 .3 . Et h e r e a l ou t pu t .

t cpsh ow

Tcpshow is good at t ranslat ing t he header field values relieving you of having t o know what field is where, com put ing exact lengt hs, and figuring out hex values. I t also at t em pt s t o int erpret t he payload. I f t he payload is ASCI I , it can be t ranslat ed. But , t here are also services such as Net BI OS t hat have addit ional layers of t ranslat ion t hat are not done by t cpshow and t he out put is incoherent . Rem em ber t hat unless you increase t he default snapshot lengt h of 68 byt es, m ost of t he t im e you will not capt ure t he ent ire dat agram . This m eans t hat not all of t he payload will be available for int erpret at ion by t cpshow. Tcpshow can be run by using t he following com m and:

tcpdump

-enx | tcpshow –nolink

This com m and reads TCPdum p records from t he net work and feeds t hem t o t cpshow. We use t he TCPdum p opt ions of - enx t o read t he fram e header for int erpret at ion purposes ( t he –e opt ion) , not resolve host nam es ( t he –n opt ion) , and dum p t he out put in hex ( t he –x opt ion) . The –nolink opt ion in t cpshow says not t o display t he fram e header inform at ion like MAC addresses. Here is som e out put from an I CMP record t hat was capt ured:

Packet 1 IP Header Version: Header Length: Service Type: Datagram Length: Identification: Flags: Fragment Offset: TTL: Encapsulated Protocol: Header Checksum: Source IP Address: Destination IP Address:

4 20 bytes 0x00 40 bytes 0xB5CB MF=off, DF=on 0 254 ICMP 0xB229 1.2.3.4 4.3.2.1

ICMP Header Type: Checksum:

echo-reply 0xBC9C

ICMP Data . sparky.1548: S 2401927088:2401927088(0) win verbo.47247 > sparky.24: S 2401927088:2401927088(0) win 2048 verbo.47247 > sparky.1547: S 2401927088:2401927088(0) win verbo.47247 > sparky.2564: S 2401927088:2401927088(0) win verbo.47247 > sparky.1484: S 2401927088:2401927088(0) win verbo.47247 > sparky.1460: S 2401927088:2401927088(0) win verbo.47247 > sparky.628: S 2401927088:2401927088(0) win 2048 verbo.47247 > sparky.1112: S 2401927088:2401927088(0) win

Alt hough we would expect t he source port of scanner verbo t o change for each new SYN connect ion t o new port s of t arget host sparky, t he source port num ber rem ains const ant as 47247. I n cont rast , look at t he default behavior exhibit ed by anot her scanning t ool known as hping2. The –S opt ion of hping2 perform s a different kind of SYN scan. I t increm ent s t he source port as expect ed, yet it at t em pt s t o open dest inat ion port 0 of it s t arget . The int ent of t his t ype of scan obviously is not t o find a list ening port . This t ype of scan is used t o elicit a RESET response t o see if a host is alive, because t here should be no host s list ening at port 0. Here's t he out put from hping2:

hping2 –S sparky 09:44:13.882207 09:44:14.876837 09:44:15.876836 09:44:16.876832

verbo.1788 verbo.1789 verbo.1790 verbo.1791

> > > >

sparky.0: sparky.0: sparky.0: sparky.0:

S S S S

1553132317:1553132317(0) win 512 1894028093:1894028093(0) win 512 2032501562:2032501562(0) win 512 851202745:851202745(0) win 512

TCP Ch e ck sum s As m ent ioned previously, t he em bedded prot ocols have checksum s as well. These cover t he em bedded header and respect ive dat a for TCP, UDP, and I CMP. Unlike t he I P checksum , t hese are end- t o- end checksum s calculat ed by t he source and validat ed by t he dest inat ion host - only. The TCP checksum has been chosen t o represent t he em bedded prot ocol checksum s. UDP does not require a checksum t o be com put ed, unlike I P, TCP, and I CMP. However, it is highly recom m ended. The em bedded prot ocol checksum s for TCP and UDP are com put ed using a pseudo- header in addit ion t o t he em bedded prot ocol header and dat a. A pseudoheader consist s of 12 byt es of dat a depict ed in Figure 9.1: t he source and dest inat ion I Ps, t he 8- bit prot ocol found in t he I P header, and a repet it ion of t he em bedded prot ocol lengt h ( t his is t he prot ocol header lengt h plus t he num ber of dat a byt es) . The zero- pad field found in t he 8 t h byt e offset is used t o pad t he 8- bit prot ocol field t o 16 bit s because checksum s are perform ed on 16- bit blocks of dat a. Figu r e 9 .1 . TCP ch e ck su m pse u do- h e a de r fie lds.

Why is t he pseudo- header necessary? This is a double check t hat is used by t he receiving host t o validat e t hat t he I P layer has not accident ally accept ed a dat agram dest ined for anot her host or t hat I P has not accident ally t ried t o give TCP a dat agram t hat is for anot her prot ocol. I f t here is som e errant corrupt ion t hat occurs in t ransit , t he validat ion of t he I P checksum m ay or m ay not discover t his, but som e fields from t he I P header are included in t he pseudo- header checksum com put at ion t o help prot ect against t his. Let 's exam ine a very specific exam ple of how t he pseudo- header prot ect s against delivering t he packet t o t he wrong host . Figure 9.2 is offered t o assist in visualizing t he process. Assum e t hat we have a host t hat sends a packet t o dest inat ion I P 1.2.3.4. We will use TCP as t he em bedded prot ocol, but it really doesn't m at t er if t he t ransport layer is TCP or UDP because bot h use t he pseudo-

header. The t ransport layer checksum includes t he pseudo- header fields in t he checksum com put at ion. Therefore, for t he dest inat ion I P, a value of 1.2.3.4 is used in t he TCP checksum com put at ion. Figu r e 9 .2 . Pse udo- he a de r ch e ck su m pr ot e ct ion.

On it s way from t he sending host , t he packet t ravels t hrough a rout er t hat , as you rem em ber, m ust validat e t he I P checksum before forwarding it . Suppose t he rout er validat es t he I P checksum , decrem ent s t he TTL, and t hen needs t o recom put e t he new I P checksum . For som e unforeseen reason, t he I P layer of t he rout er som ehow corrupt s t he dest inat ion I P t o be 1.2.3.5. The I P checksum is recom put ed using t he corrupt ed dest inat ion I P. The I P checksum is valid so t he packet cont inues on t owards t he wrong dest inat ion, I P 1.2.3.5. Assum e t hat t he I P 1.2.3.5 exist s. The corrupt ed packet arrives at t he wrong dest inat ion I P. The I P layer validat es t he checksum and it is correct because dest inat ion I P 1.2.3.5 was used in t he I P checksum com put at ion by t he corrupt ing rout er. The packet is pushed up t o t he t ransport layer where TCP uses t he pseudoheader fields in t he checksum validat ion. But , t he TCP checksum validat ion uses dest inat ion I P 1.2.3.5 in t he corrupt ed packet I P header for validat ion com parison against t he packet 's act ual TCP checksum . However, t his does not m at ch t he TCP pseudo- header checksum from t he sending host t hat used 1.2.3.4 as t he dest inat ion I P in t he pseudo- header checksum . Host 1.2.3.5 t hen discards t he packet because t he em bedded prot ocol checksum does not m at ch t he com put ed checksum done by t he dest inat ion host .

A Cr y for H e lp While reading lit erat ure on t he purpose of t he pseudo- header, it m ade perfect sense t o m e t hat it is used as an addit ional check t o m ake sure t hat t he packet isn't sent t o t he wrong host or prot ocol. Yet , for t he life of

m e, I couldn't envision how t his was done. I asked several colleagues, but t hey t oo shared m y confusion when it cam e t o giving an exam ple. I ended up writ ing not ed aut hor and TCP/ I P expert , Doug Com er, who shared t he exam ple of a rout er corrupt ing t he dest inat ion I P num ber. I would like t o ext end m any t hanks t o Mr. Com er for clearing up t he confusion. TCP Se qu e n ce N u m be r s The TCP sequence num bers are used t o uniquely ident ify t he beginning byt e of each TCP segm ent t hat is sent . This is a way t o keep t rack of all t he TCP dat a t hat is sent and received in a TCP st ream . Most t im es, t here is m ore TCP dat a t han can be sent in one TCP segm ent . Or, som e services such as rlogin m ight send a charact er at a t im e over a TCP st ream requiring m ult iple st ream s per session. Because TCP is a reliable prot ocol, we m ust have a m echanism t o account for dat a being sent and received. I n part , t hat is done using TCP sequence num bers. These sequence num bers should not be repeat ed unless t here is a ret ry of t he sam e connect ion if an init ial at t em pt fails and t he sender receives no error from eit her t he int ended receiver or som e kind of packet - filt ering device. The init ial sequence num ber ( I SN) is t he first sequence num ber t hat is used in t he TCP exchange bet ween t he sending and receiving host s. Each host in t he exchange select s a unique init ial sequence num ber when sending t he init ial SYN connect ion t o t he ot her host . The form ula t hat TCP/ I P st acks use t o select t heir init ial sequence num ber is exam ined by nm ap t o help fingerprint t he operat ing syst em . There is a file t hat com es wit h nm ap, nm ap- os- fingerprint s, t hat has a list of m any different operat ing syst em s and versions. Nm ap perform s a given set of t est s against a t arget host . Nm ap can cat egorize a part icular operat ing syst em by m at ching t he values in responses t o different norm al and abnorm al st im uli sent by t he scanning host wit h t he expect ed values for a given operat ing syst em . The first t est execut ed by an operat ing syst em fingerprint ing nm ap scan is one t hat exam ines t he init ial sequence num bers generat ed by a receiving host from sent connect ions t o a list ening port . Different TCP/ I P st acks use different form ulas t o generat e t he I SN. Som e of t he older operat ing syst em s used a predict able increm ent for t he I SN for each new connect ion. But som eone wat ching and sniffing could possibly predict and hij ack a connect ion using t his inform at ion, as was done in t he infam ous Mit nick at t ack. Ot her operat ing syst em s have a t im e- dependent form ula t hat predict ably increases t he I SN based on a given t im e change. This, t oo, is not considered very secure. The m ost secure form ula for I SN generat ion is a random , unpredict able one. As a t idbit of inform at ion, t he SYN t hat we refer t o as t he flag t o st art a TCP connect ion is act ually an abbreviat ion for synchronize sequence num bers. The following execut ion of nm ap using t he operat ing syst em fingerprint scan opt ion ( - O) shows open port s, TCP sequence num ber predict ion

difficult y, and guessed operat ing syst em .

nmap –O sparky (The 1495 ports scanned but not shown below are in state: closed) Port State Service 23/tcp open telnet 25/tcp open smtp 111/tcp open sunrpc 513/tcp open login 32771/tcp open sometimes-rpc5 32772/tcp open sometimes-rpc7 TCP Sequence Prediction: Class=random positive increments Difficulty=46112 (Worthy challenge) Remote OS guesses: Solaris 2.6 - 2.7, Solaris 7

Using nm ap –O t o scan t he Solaris host sparky and ident ify t he operat ing syst em discovers t hat t he generat ion of init ial sequence num bers is based on a form ula using " random posit ive increm ent s." And, it report s t hat predict ing a new TCP sequence num ber would be a " wort hy challenge." Sparky is a Solaris 2.7 host , and it appears t o be fairly im pervious t o som eone guessing a new TCP sequence num ber based on a previous one or based on t im e. Ack n ow le dge m e n t N u m be r s The m et hod t hat TCP uses t o ensure t hat dat a is received is via an acknowledgem ent . The receiving host set s t he acknowledgem ent flag and t he acknowledgem ent num ber, which are validat ion t hat t he receiving host did indeed get t he dat a. The acknowledgem ent num ber sent by t he receiving host act ually represent s t he next expect ed TCP sequence num ber it should receive. Because a SYN connect ion consum es one sequence num ber, and because t he acknowledgem ent value is one m ore t han t his sequence num ber, a valid acknowledgem ent num ber m ust be great er t han 0. There is one rare qualificat ion of t his. I t is possible t o use all 2 billion plus TCP sequence num bers available wit h t he 32- bit field in which t hey are st ored. I f, by chance, t he last TCP sequence num ber sent is t he largest 32- bit num ber allowed, t he receiving host wraps around and acknowledges t hat t he next expect ed sequence num ber is 0. This is an infrequent occurrence. Nm ap can at t em pt t o ident ify live host s by sending a rem ot e host a TCP connect ion wit h an unsolicit ed ACK flag set . This m et hod of host ident ificat ion is oft en m ore successful t han pinging t he host because m any sit es now block inbound I CMP echo request s. Yet , a rout er t hat doesn't m aint ain st at e m ay allow in " est ablished" t raffic in which t he ACK flag is set . The desired response t o t he unsolicit ed ACK is a RESET from t he rem ot e host , which indeed indicat es t hat t he rem ot e host is alive regardless of whet her t he scanned port is list ening. Current

versions of nm ap have a t ellt ale signat ure because t he ACK flag is set , yet t he acknowledgem ent num ber is 0 as shown in t he following out put .

verbo.52776 > win98.netbios-ssn: . ack 0 win 4096

TCP Fla gs TCP flags are used t o indicat e t he funct ion of a given TCP connect ion or session. The SYN flag st art s a session and t he FI N flag t erm inat es a session gracefully. A RESET is used t o abort a session. The ACK flag is set t o indicat e an acknowledgem ent of dat a by t he receiver. The ACK flag is set on all packet s aft er t he init ial SYN. The PUSH flag is t ypically used t o t ell t he sending host t o writ e all of it s buffered dat a t o send t o t he dest inat ion host and for t he dest inat ion host t o PUSH it up t o t he TCP layer. I t is act ually possible t o send dat a wit hout t he PUSH flag set when all of t he dat a in t he sending buffer is not com plet ely em pt ied. Finally, t he URGENT flag is used t o indicat e t hat dat a has t he highest priorit y. The TCP flags have m any different valid com binat ions. And, t here are m any different invalid com binat ions t hat are used for different purposes. Early in t he evolut ion of NI DS, m any would exam ine t raffic for init ial SYN at t em pt s only. Scanners realized t his and would send a SYN/ FI N com binat ion t hat m ight elicit a response from a host . Different operat ing syst em TCP/ I P st acks respond different ly t o m ut ant flag set t ings, so t his is used t o at t em pt t o fingerprint t he operat ing syst em . We will exam ine som e of t he sit uat ions in which valid and invalid flag com binat ions can occur over t he next several sect ions. TCP Cor r u pt ion

Just because you see m ut ant TCP flag com binat ions, it is not necessarily an indicat ion of m alicious behavior. Packet s can and do get corrupt ed, and it is possible for TCP flags t o be unnat urally set aft er som e kind of corrupt ion in t he TCP port ion of t he packet . Look at t he following packet received on a Shadow NI DS. This was an at t em pt ed Napst er connect ion back in t he days when Napst er was a free and legal m et hod of exchanging MP3s:

host.home.com.1310 > napster.com.6699: SRP [bad hdr length] (DF)

There are t wo anom alies t hat st and out looking at t he record. The first is t he m ut ant flag set t ings of SRP, m eaning t hat all t hree of t he SYN, RESET, and PUSH flags are set sim ult aneously. The next sign is TCPdum p's not at ion of bad hdr length.

A bad hdr length is an error generat ed by TCPdum p when t he specified TCP header lengt h is great er t han t he act ual TCP segm ent ( header and dat a) lengt h. Because t here is no field in t he I P dat agram t hat holds t he value of t he TCP segm ent lengt h ( header and dat a) , TCPdum p com put es t his value by using fields it does have. I t subt ract s t he I P header lengt h from t he I P dat agram t ot al lengt h. For properly form at t ed packet s, t his reflect s t he t rue TCP segm ent lengt h. One of t he validit y checks perform ed by TCPdum p is t o t est if t he packet 's specified TCP header lengt h in byt es is great er t han t he com put ed TCP segm ent lengt h. I f t his com parison is t rue, t here is som et hing definit ely wrong wit h a lengt h field, and t hat is when t he bad hdr length error is displayed. I t will be becom e apparent why TCPdum p believes t his by exam ining t he following hex dum p out put . First , t he I P header is cont ained bet ween t he bracket s and t he TCP header bet ween t he less t han and great er t han signs:

[4500 0028 8974 4000 7406 a9c5 1804 ee22 80f4 4c7b]

Now let 's t urn our at t ent ion t o t he lengt h fields in t he packet . First , look at t he I P t ot al dat agram lengt h in t he bolded 2 nd and 3 rd byt es offset of t he I P header. You should see a 0x28 or 40- byt e I P dat agram lengt h. The I P header lengt h is found in t he bolded low- order nibble of t he 0 byt e offset of t he I P header. As we know, t his value of 5 represent s a 20- byt e I P header. The prot ocol field in t he 9 t h byt e offset of t he I P header has been bolded t o highlight t he em bedded prot ocol. Because we discover a 06 in t hat field, we know t hat a TCP header follows. The com put ed TCP segm ent lengt h is t hen 40–20, giving us 20 byt es for TCP header and dat a. This is room enough for a TCP header wit h no opt ions and no dat a such as m ight be found on a plain SYN at t em pt . Yet , in t he TCP header lengt h, we find a lengt h of 0xa in t he bolded high- order nibble of t he 12 t h byt e offset , which indicat es a 40- byt e TCP header aft er we m ult iply it by 4 t o t ranslat e from 32- bit words t o byt es. Using t hese fields, do you know why TCPdum p generat es t he bad hdr length error? This is a dat agram wit h a t ot al lengt h of 40, including a 20- byt e I P header lengt h, yet a TCP header t hat professes t o be 40 byt es. We need a m inim um I P dat agram lengt h of 60 t o house t his dat a if indeed t here has been no corrupt ion. I s it possible t hat t his packet has been corrupt ed and t he checksum is invalid? Rem em ber, if t his involved packet corrupt ion in t he TCP header or dat a, t he only host t hat will det ect t his is t he dest inat ion host . The NI DS sensor t ypically does not validat e a TCP checksum .

Here is what we can deduce about t his packet . Chances are t hat t he I P header is fine because t he previous rout er did not drop it . Rout ers are supposed t o validat e t he I P checksum s and silent ly drop packet s wit h inaccurat e ones. Now, before reaching t he dest inat ion host and having t he TCP checksum validat ed, it passes by t he sensor where TCPdum p finds a problem wit h it . I t is possible t hat t he rout er corrupt ed t he I P header aft er t he checksum was com put ed, but t he header ot herwise appears t o be norm al. At t his point , we don't know if t he packet has been accident ally corrupt ed or int ent ionally corrupt ed for what ever reason. The only ot her ways t o verify packet corrupt ion is t o m anually com put e t he checksum of t he received packet on t he sensor or exam ine how t he receiving host ( napst er.com ) react s. The problem wit h looking at how napst er.com react s is t hat if t he checksum is invalid, we will see no response. Yet , if t he checksum is valid, t his weird com binat ion of flags m ight not elicit a response eit her. I f we do observe an unlikely response from napst er.com ( m ost likely a RESET) , t his m eans t hat t he checksum is valid and t he packet wasn't corrupt ed on rout e from source t o dest inat ion. This m eans t hat t he packet was m ost likely craft ed wit h m ut ant values at t he source. Too, t here is always t he possibilit y of cleanly swapped 16- bit fields t hat would corrupt t he packet , but t here would be no m anifest at ion of it in t he checksum . Vern Paxson, creat or of an I DS nam ed Bro, t alks of t raffic he has labeled " crud" in his paper " Bro: A Syst em for Det ect ing Net work I nt ruders in Real- Tim e." His definit ion of crud is " innocuous im plem ent at ion errors" t hat creat e t raffic pat t ern pat hologies t hat look sim ilar t o genuine at t acks. He cit es exam ples of an errant TCP/ I P st ack t hat rout inely set s t he URG flag on a SYN at t em pt and anot her t hat set s t he DF flag on t raffic fragm ent s. Alt hough t his is different t han packet corrupt ion, t he im port ant point t o keep in m ind is t hat not all- anom alous t raffic you wit ness is m alicious. I t is rem ot ely possible t hat a very sm all am ount is due t o corrupt ion, or crud. ECN Fla g Bit s

Unt il very recent ly, t he t wo high- order bit s of t he TCP byt e were known as t he reserved bit s. They had no purpose, and t he value found in t he bit s should have been 0. However, when t ools such as nm ap cam e along, it was discovered t hat t hese bit s could be used t o t ry t o help fingerprint a rem ot e operat ing syst em . Different operat ing syst em TCP/ I P st acks would respond uniquely when t hese bit s were set . Som e would reset t he bit s t o 0, and ot hers would sim ply leave t hem wit h t he current value. Hence, som e insight could be m ade of t he rem ot e host 's operat ing syst em TCP/ I P st ack. This alone m ight not be enough t o inform t he scanner of t he operat ing syst em , but used in conj unct ion wit h several ot her t est s, t he operat ing syst em could be conj ect ured wit h a high probabilit y. Rem em ber back when we were discussing t he different iat ed services byt e in

Chapt er 8, " Exam ining I P Header Fields," we int roduced a new purpose for t he t wo low- order bit s known as Explicit Congest ion Not ificat ion ( ECN) ? The int ent was for a rout er t o be able t o not ify a sender t hat t here was congest ion in t he net work and t o reduce it s sending rat e. How exact ly does t hat occur? Current ly, as discussed in t he ECN RFC 3168, t he only t ransport capable of react ing t o t hat congest ion not ificat ion is TCP. So, TCP m ust be prepared t o deal wit h t his. The RFC offers using t he t wo high- order bit s of t he TCP flag byt e ( see Figure 9.3) as fields for ECN. The bit t o t he right of t he high- order bit is known as t he ECN- echo bit . This bit is t urned on when TCP receives a packet t hat has t he Congest ion Experienced bit s set in t he different iat ed services byt e of t he I P header. This m eans t hat bot h end- point s of t he TCP conversat ion are ECN- capable, which is det erm ined during t he t hree- way handshake. Figu r e 9 .3 . The ECN bit s of t h e TCP fla g by t e .

I f TCP set s t he ECN- echo bit , t he purpose is t o inform t he sender t o reduce t he rat e at which it is sending dat a because t here is congest ion bet ween t he sender and receiver. Upon receipt of a TCP segm ent wit h t he ECN- echo bit set , t he sender reduces it s congest ion window, t he size of t he sending buffer, by half. Aft er it react s in t his m anner, it t urns on t he Congest ion Window Reduced ( CWR) bit t o inform t he ot her side of t he conversat ion t hat rem edial act ion t o reduce congest ion has occurred. This bit is found in t he high- order bit of t he TCP byt e flag. Alt hough t his m echanism helps reduce t he num ber of packet s dropped, it is ant icipat ed t hat m any exist ing NI DS will begin t o alarm on t hese new TCP flag byt es being used. Right now, m ost uses of t hese bit s are for scanning purposes only. Also, som e packet - filt ering devices will not allow inbound TCP segm ent s wit h t hese bit s set . So, m uch cust om izat ion will have t o be done t o sm oot hly int roduce ECN and dist inguish it from t he rogue scans. Ope r a t in g Syst e m Fin ge r pr in t in g

When nm ap is placed in operat ing syst em fingerprint ing m ode wit h t he –O opt ion, it sends som e m ut ant flag com binat ions when an open port is discovered. Look at

t he following out put from nm ap rem ot e operat ing syst em scans:

nmap –O win98 20:33:16.409759 verbo.47322 > win98.netbios-ssn: SFP 861966446:861966446(0) win 3072 urg 0 20:33:16.410387 win98.netbios-ssn > verbo.47322: S 49904150:49904150(0) ack 861966447 win 8215 (DF) nmap –O sparky 20:37:00.738412 verbo.50107 > sparky.echo: SFP 2326441544:2326441544(0) win 2048 urg 0 nmap –O linux 20:44:50.370158 verbo.42318 > linux.ftp: SFP 1749165064:1749165064(0) win 1024 urg 0

I n t he first scan of a Windows 98 host , t he m ut ant flag com binat ion of SYN/ FI N/ PUSH/ URG is sent t o t he Windows port 139. This is a Net BI OS session service port , and t he Windows host list ens on t his port . Yet , am azingly enough, it responds wit h an acknowledgem ent ! This behavior is not what we expect . I n t he second nm ap scan, t he sam e t echnique of sending t he m ut ant com binat ion of SYN/ FI N/ PUSH/ URG flags t o a list ening Solaris port ( echo) is at t em pt ed, and no response is elicit ed. This sam e com binat ion of flags is sent t o a list ening Linux ft p port in t he t hird scan, and no response is received. This is t he expect ed behavior, which conform s t o RFC specificat ions. Yet , you can see how t his t est can be used t o dist inguish Windows host s from all ot hers. As a new analyst , it is oft en difficult t o dist inguish bet ween what appears t o be m alicious behavior and TCP/ I P st acks t hat don't conform t o t he RFC specificat ions. I t is hard t o underst and t he int ent when a response isn't as you expect . Many t im es, even an experienced analyst does not know if abnorm al TCP flag set t ings are an indicat ion of som e wayward TCP/ I P st ack or som eone up t o no good. Re t r a n sm ission s

What if an init ial TCP connect ion is at t em pt ed, yet t he host at t em pt ing t he connect ion doesn't receive a response from t he dest inat ion host ? A dest inat ion host m ight not respond because it m ight not be up or m ight not exist . A rout er m ight at t em pt t o deliver an I CMP m essage about t he dest inat ion host being unreachable, but if t he rout er has been silenced from delivering unreachable m essages, t he sending host will never know t hat t here is a problem . A dest inat ion host m ight be sit t ing behind som e kind of packet - filt ering device t hat blocks t he connect ion inbound, yet silent ly drops t he connect ion wit hout inform ing t he sending host .

I t is also possible t hat t he dest inat ion host responds posit ively ( SYN/ ACK) or negat ively ( RESET/ ACK) , yet for som e reason t he sending host doesn't receive t hese replies. Addit ional at t em pt s or ret ransm issions are m ade t o cont act t he host in sit uat ions like t his. The num ber of ret ransm issions and t he t im e int ervals in which t hey are at t em pt ed varies by TCP/ I P st ack. Event ually, t he sending host ceases t he connect ion at t em pt s. How can you dist inguish ret ransm issions or ret ries from separat e new TCP connect ions t o a dest inat ion host ? The source port s rem ain t he sam e, and t he TCP sequence num bers don't change for ret ransm issions. This is not a fail- safe det ect ion m et hod. I t is also possible t hat t he sender is craft ing packet s t hat use t he sam e source port s and TCP sequence num bers. Exam ine t he following set of ret ries—specifically, look at t he t im e and t he I P ident ificat ion num ber changes. The I P ident ificat ion num bers should change on a ret ry as well as a set of unique connect ions. The sending host generat es an ent irely new packet for t he ret ry so t he I P ident ificat ion num ber should increm ent or wrap:

17:14:18.726864 1.1.1.1.62555 > 192.168.44.63.3128: win 8192 (DF) (ttl 17, id 15697) 17:14:21.781140 1.1.1.1.62555 > 192.168.44.63.3128: win 8192 (DF) (ttl 17, id 33873) 17:14:27.776662 1.1.1.1.62555 > 192.168.44.63.3128: win 8192 (DF) (ttl 17, id 46113) 17:14:39.775929 1.1.1.1.62555 > 192.168.44.63.3128: win 8192 (DF) (ttl 17, id 54353)

S 20583734:20583734(0) S 20583734:20583734(0) S 20583734:20583734(0) S 20583734:20583734(0)

Now, look at t he t im e changes bet ween at t em pt ed ret ries. Bet ween t he first and second connect ion at t em pt s, t he wait is approxim at ely 3 seconds. This doubles t o 6 seconds bet ween t he second and t hird connect ions. And, finally, t his doubles again t o 12 seconds bet ween t he t hird and fourt h at t em pt s. This doubling of t he backoff t im e m ight not always be wit nessed—different TCP/ I P st acks use different ret ry- t im e algorit hm s for t he subsequent ret ries. Oft en, analyst s not fam iliar wit h t he concept of ret ries m isread what is happening here. They erroneously believe t hat an at t acker is at t em pt ing m ult iple connect ions t o t he dest inat ion host . I nst ead, t he ret ries are aut om at ically generat ed by TCP. Usin g Re t r a n sm ission s Aga in st a H ost ile H ost —La Br e a Ta r pit Ve r sion 1

A very clever defender against t he Code Red worm scans of web servers, Tom List on, wrot e a program t hat " t arpit s" scanners looking for unassigned I P num bers. Typically, when you see act ivit y t o an unassigned I P address, it m ight m ean som eone is scanning host s on your net work. He nam ed his code LaBrea

aft er t he La Brea Tar Pit . Here is how LaBrea works. I t is inst alled on a local host and first list ens for ARP request s t o unassigned I P num bers. Usually, a rout er generat es t his ARP request for t he unknown I P num ber. When no ARP reply is generat ed by a real host aft er t hree seconds, t he LaBrea host fakes a response t o an ARP reply. I f a SYN follows from t he scanning host ( in t his case, usually an infect ed Code Red host ) , t he LaBrea host fakes a SYN/ ACK response. LaBrea does not exam ine t he dest inat ion port , so t his program could be used against any TCP scan or at t em pt ed TCP connect ion t o an unassigned I P num ber. The scanning host t hen com plet es t he t hree- way handshake and at t em pt s t o send som e dat a. The LaBrea host now deliberat ely fails t o respond by never ACKing t he dat a sent by t he scanning host . Thus, t he scanning host is t arpit t ed in ret ransm issions unt il it t im es out . This consum es resources on t he scanning host and slows it s capabilit y t o scan, especially if it wait s for a response t o proceed wit h furt her scanning. Let 's exam ine what happens st ep by st ep in t he LaBrea t arpit :

ARP request for unassigned IP 192.168.143.236 18:34:32.757821 arp who-has 192.168.143.236 tell 192.168.143.1 18:34:35.743528 arp who-has 192.168.143.236 tell 192.168.143.1 After 3 seconds and no ARP reply, LaBrea host fakes reply 18:34:35.743591 arp reply 192.168.143.236 (0:0:f:ff:ff:ff) is-at 0:0:f:ff:ff:ff

First , LaBrea looks for ARP request s on t he local net work. These usually com e from t he local rout ing device. I f it sees no ARP reply aft er t hree seconds ( t his is t he default wait t im e, however it can be changed by a com m and line opt ion) , it fakes an ARP reply. I n t his case, we see an ARP request for host 192.168.143.236 from t he local rout er 192.168.143.1. This is an unassigned I P num ber. No ARP reply is seen and anot her ARP request is generat ed t hree seconds aft er t he init ial one. Aft er t hree seconds, t he LaBrea host fakes an ARP reply and t ells 192.168.143.1 t hat t he MAC address for 192.168.143.236 is a bogus 0: 0: f: ff: ff: ff. Neit her t he 192.168.143.236 address nor t he MAC address is real. This is a way t o allow t he rout ing device t o respond t o t he scanner wit hout generat ing an I CMP unreachable error. Now, t he LaBrea host will look for any t raffic dest ined for t he bogus MAC address going across t he net work. Aft er t he bogus MAC address is generat ed by LaBrea, t he scanning host 's SYN at t em pt is answered by t he LaBrea host sim ulat ing a list ening host and port as shown.

Infected Code Red host requests SYN 18:34:35.743817 codered.victim.com.1113 > 192.168.143.236.www: S 301190748:301190748(0) win 8192 (DF) LaBrea host spoofs ACK 18:34:35.743940 192.168.143.236.www > codered.victim.com.1113: S 2516582400:2516582400(0) ack 301190749 win 10 Infected Code Red host completes three-way handshake 18:34:35.744190 codered.victim.com.1113 > 192.168.143.236.www: . ack 1 win 8576 (DF)

I n t he previous out put , you see t he codered.vict im .com host at t em pt a SYN connect ion t o t he unassigned dest inat ion I P address 192.168.143.236 dest inat ion port 80 ( www) . LaBrea t hen generat es a response t o t his connect ion wit h a SYN/ ACK from t he non- exist ent I P address 192.168.143.236. And, as expect ed, t he codered.vict im .com host com plet es t he t hree- way handshake. The connect ion is now " est ablished." Next , t he codered.vict im .com host at t em pt s t o send 10 byt es of dat a t o fill t he receive buffer of t he bogus web server 192.168.143.236 as can be seen in t he following out put :

Code Red host sends 10 bytes of data 18:34:35.745555 codered.victim.com.1113 > 1 win 8576 (DF) Retransmission at +6 seconds 18:34:41.746643 codered.victim.com.1113 > 1 win 8576 (DF) Retransmission at +12 seconds 18:34:53.743027 codered.victim.com.1113 > 1 win 8576 (DF) Retransmission at +24 seconds 18:35:17.735734 codered.victim.com.1113 > 1 win 8576 (DF) Retransmission at +48 seconds 18:36:05.741181 codered.victim.com.1113 > 1 win 8576 (DF) Retransmission at +96 seconds 18:37:41.911995 codered.victim.com.1113 > 1 win 8576 (DF) 3 minutes 6 seconds later retransmissions

192.168.143.236.www: . 1:11(10) ack

192.168.143.236.www: . 1:11(10) ack

192.168.143.236.www: . 1:11(10) ack

192.168.143.236.www: . 1:11(10) ack

192.168.143.236.www: . 1:11(10) ack

192.168.143.236.www: . 1:11(10) ack stop

There is no PUSH flag set as you are used t o seeing because t he PUSH flag is only set when t he sending host em pt ies it s sending buffer. But , because codered.vict im .com 's send buffer is great er t han 10 byt es, t he only flag you see is t he ACK flag acknowledging receipt of t he bogus init ial SYN connect ion from 192.168.143.236.

Now, here com es t he t arpit . There is no acknowledgem ent of t he dat a sent by codered.vict im .com . So, it m ust ret ransm it t he dat a. The ret ransm ission t im er for t his part icular host has an exponent ial backoff where it doubles t he t im e bet ween ret ries. Of t he several runs of LaBrea at t em pt ed, t he first ret ry varied in wait t im e from t hree t o t welve seconds aft er t he init ial t ry. Several at t em pt s used t he sixsecond wait as m anifest ed in t he previous out put . Five ret ries and t hree m inut es and six seconds aft er t he init ial at t em pt t o send dat a, t he codered.vict im .com host gives up. But it has expended resources and been delayed in it s scanning for t his durat ion. I f t he scanning host wait s for t he response from t he LaBrea host before cont inuing t he scan, it has been slowed down in it s effort s. This is m ore effect ive if t he scanning host is t arpit t ed over and over again for all unassigned I Ps on t his net work. Alt hough it appears very t em pt ing t o use LaBrea, m ake sure t hat you underst and t he im plicat ions of doing so. First , as current ly writ t en, t he t arpit is perform ed for any TCP connect ion for which t here is no real dest inat ion I P, regardless of dest inat ion port num ber. I f a real host in t he net work t em porarily experiences problem s and is unable t o respond t o an ARP request , legit im at e connect ions m ight be erroneously t arpit t ed. Also, it appears t hat firewalls t hat m aint ain st at e t ables of connect ions can becom e encum bered by t he t arpit t ed connect ions. LaBrea code can be found at ht t p: / / www.hackbust ers.net / .

La Br e a Ta r Pit La Brea Tar Pit is locat ed in Los Angeles's Hancock Park. I t was t he sit e of a nat ural accum ulat ion of t ar t hat form ed over oil. During t he Early Pleist ocene t im e ( about 2.5 m illion years ago) , anim als becam e t arpit t ed and died when at t em pt ing t o drink at t he sit e or cross t he t ar form at ion. TCP W in dow Size The TCP window size is t he m et hod em ployed by a receiving host t o inform t he sending host of t he current buffer size for dat a sent for t hat connect ion. This is a flow cont rol m echanism because it is dynam ic. The window size becom es sm aller for all dat a t hat has been received, but not yet processed by t he receiving host . I f t he receiving buffer ever becom es full, t he window size becom es 0 inform ing t he sending host t o t em porarily halt t ransm ission of any m ore dat a. Aft er t he receiving host has processed som e of t he dat a in t he buffer, it sends a window size updat e t o t he sending host t o inform it t o resum e sending dat a. As you can see, flow of cont rol for TCP sessions is m ost ly done by t he receiving host by use of t he window size. We have a t endency t o assum e t hat t he sender is really t he one cont rolling t he flow of dat a across t he net work. But , for t he m ost part , t he receiver is t he direct or of t he dat a flow.

I nit ial window sizes are used by nm ap t o det erm ine t he operat ing syst em . Different TCP/ I P st acks select different init ial window sizes, which is used t o help fingerprint t he operat ing syst em . La Br e a Ve r sion 2

I f you recall, t he original version of LaBrea was able t o slow down a scanning or at t acking host for t he am ount of t im e it t ook t he at t acker's TCP connect ion t o t im e out from lack of a response aft er t he t hree- way handshake. Depending on t he at t acker's TCP/ I P st ack im plem ent at ion of t he num ber of ret ries and t he backoff t im e bet ween t im eout s, t he at t acker could be delayed several m inut es. LaBrea's aut hor, Tom List on, im proved on his own concept using anot her t echnique known as t he TCP persist t im er. As we j ust learned, if a receiving host 's TCP window is filled and it cannot accept any m ore dat a from t he sender, it not ifies t he sender t o cease sending dat a by set t ing t he window size t o 0. Ordinarily, when t he receive buffer frees up space by sending t he dat a t o TCP, a TCP segm ent follows wit h a window size great er t han 0. What if t his new window advert isem ent is lost ? Bot h sender and receiver would be frozen wait ing for t he ot her t o act . There is a m echanism t o deal wit h t his known as a window probe. Aft er a t im er expires and t he sender has not received any new window advert isem ent from t he receiver, t he sender t ransm it s a TCP window probe t hat carries 1 byt e of payload wit h t he exclusive purpose of solicit ing a response from t he receiver t o discover if t he window size has been increased. The sender persist s in sending window probes unt il t he window size increases or unt il eit her of t he end- host applicat ions t erm inat es. The new version of LaBrea uses t he persist t im er t o t arpit t he at t acker for an indefinit e am ount of t im e, as you can see from t he following TCPdum p out put . I t works exact ly like t he previous version of LaBrea up t hrough t he t hree- way handshake. I nst ead of not responding, LaBrea react s t o t he sender's dat a wit h an acknowledgem ent , but wit h a window size of 0. I t doesn't increase t he window size via a window updat e forcing t he scanner t o send a window probe. The LaBrea host responds t o t he window probe, but again advert ises t he window size as 0. This pat t ern of window probe and a response of a window size of 0 cont inues indefinit ely. This t arpit s t he at t acker int o a persist ent connect ion wit h t he LaBrea host if t here is no int ervent ion. Take a look at t he out put :

19:28:07.577541 codered.victim.com.2045 > 10.10.10.155.www: S 882335286:882335286(0) win 8192 (DF) 19:28:07.577618 10.10.10.155.www > codered.victim.com.2045: S 998514038:998514038(0) ack 882335287 win 5 19:28:07.577879 codered.victim.com.2045 > 10.10.10.155.www: . ack 1 win 8576 (DF)

19:28:07.581366 win 8576 (DF) 19:28:07.581437 19:28:09.820965 win 8576 (DF) 19:28:09.821041 19:28:14.424567 win 8576(DF) 19:28:14.424646 19:28:23.621770 win 8576 (DF) 19:28:23.621845 19:28:42.016162 win 8576 (DF) 19:28:42.016237 19:29:18.804962 win 8576 (DF) 19:29:18.805038

codered.victim.com.2045 > 10.10.10.155.www: . 1:6(5) ack 1 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0 codered.victim.com.2045 > 10.10.10.155.www: . 6:7(1) ack 1 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0 codered.victim.com.2045 > 10.10.10.155.www: . 6:7(1) ack 1 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0 codered.victim.com.2045 > 10.10.10.155.www: . 6:7(1) ack 1 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0 codered.victim.com.2045 > 10.10.10.155.www: . 6:7(1) ack 1 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0 codered.victim.com.2045 > 10.10.10.155.www: . 6:7(1) ack 1 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0

We j oin our session aft er t he faked ARP reply by t he LaBrea host . For orient a- t ion purposes, we see t he t hree- way handshake com plet ed by t he Code Red vict im host , codered.vict im .com , and t he LaBrea host pret ending t o be host 10.10.10.155. The codered.vict im .com host t hen sends 5 byt es of dat a ( in bold out put ) because t hat was t he advert ised window size of t he bogus 10.10.10.155 host . The 10.10.10.155 LaBrea host responds wit h an acknowledgem ent of receipt of dat a, but a window size of 0. The codered.vict im .com host wait s a couple of seconds when it doesn't get any not ificat ion of a window size increase and sends a 1- byt e window probe t o 10.10.10.155. The LaBrea host lazily responds t o t he window probe essent ially t elling t he inquirer t o chill out ; it is st ill alive and running, but is not ready for any dat a j ust yet . As you wit ness, t his cycle is repeat ed wit h t he probing host increasing it s wait t im e for fut ure probes and becom ing t arpit t ed indefinit ely.

UD P UDP is a m uch less com plicat ed prot ocol t o discuss t han TCP because it doesn't have any of t he fields t hat ensure reliable delivery. UDP does not m ake any guarant ees t hat dat a will be delivered and leaves t his funct ion t o applicat ions t o handle. This sect ion will exam ine t he fields found in t he UDP header and how UDP port scanning is accom plished. Por t s Just as wit h TCP port s, UDP port fields are t wo separat e 16- bit fields in t he TCP header—one for source and anot her for dest inat ion. The valid range of values is bet ween 1 and 65535; t he use of port 0 is t ypically a signat ure of unusual act ivit y. When a source host wishes t o connect t o a dest inat ion host , an ephem eral port is t ypically select ed in t he range of port s great er t han 1023. For each new sending connect ion, a different ephem eral port should be select ed.

UD P Por t Sca nn in g

Unlike TCP t hat responds wit h eit her a posit ive response ( SYN/ ACK) t o a list ening port or a negat ive response ( RESET/ ACK) t o a non- list ening port , UDP doesn't respond t o an init ial connect ion wit h any posit ive feedback. But , a live host responds wit h a negat ive response of I CMP " port unreachable" t o a non- list ening UDP port . This is how scanners det erm ine if t he UDP port is list ening or not . This is anot her m ore st ealt hy way t o scan for live host s, assum ing t he sit e does not block out bound I CMP error m essages. So, t he absence of an I CMP " port unreachable" error is const rued as an open port . What if t he scanning packet got dropped on it s way t o t he t arget host ? Or what if t he t arget host responds wit h an I CMP " port unreachable" m essage, but t he sit e blocks out bound I CMP m essages? Or what if t he sit e blocks inbound UDP and blocks all out bound I CMP or I CMP unreachable m essages so t hat t he scanner cannot receive an I CMP " adm in prohibit ed" m essage t o know t his? This can be m isconst rued as a list ening port . Nm ap scans t he sam e UDP port s m any t im es t o t ry t o deal wit h t he case of dropped packet s. I f one packet is dropped and t he net work is not under duress or having problem s, chances are one of t he repeat ed packet s will not be dropped. And once again, nm ap is int elligent enough t o know t hat t he lack of any response is m ore likely an indicat ion of filt ering of som e sort by t he dest inat ion sit e t han it is of all UDP port s list ening. This is a UDP port scan in t he 32771 t o 34000 range t o look for open Rem ot e Procedure Call ( RPC) port s on a Solaris host . Nm ap found m any of t hese port s open. I t assum es t hat a port is open if no I CMP " port unreachable" m essage was ret urned. As we have discussed, t his is not always t rue.

nmap –sU sparky –p 32771-34000 WARNING: -sU is now UDP scan -- for TCP FIN scan use -sF Starting nmap V. 2.12 by Fyodor ([email protected], www.insecure.org/nmap/) Interesting ports on sparky (1.1.1.100): Port State Protocol Service 32771 32772 32773 32774 32782 32783 32784 32785 32786 32797

open open open open open open open open open open

udp udp udp udp udp udp udp udp udp udp

unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown

The following TCPdum p out put shows a sam ple from UDP port scanning. Any port in t he scanned range t hat sparky does not generat e an I CMP " port unreachable" m essage for is assum ed t o be list ening:

07:09:08.286810 07:09:08.286847 07:09:08.286878 07:09:08.286924 07:09:08.286969 07:09:08.287046 07:09:08.287094 07:09:08.287162 07:09:08.287229

verbo.62865 verbo.62865 verbo.62865 verbo.62865 verbo.62865 verbo.62865 verbo.62865 verbo.62865 verbo.62865

07:09:08.287793 07:09:08.977544 07:09:09.657361 07:09:10.157301 07:09:10.817315

sparky sparky sparky sparky sparky

> > > > >

> > > > > > > > >

sparky.32787: sparky.32775: sparky.32788: sparky.32789: sparky.32791: sparky.32774: sparky.32781: sparky.32772: sparky.32789:

verbo: verbo: verbo: verbo: verbo:

icmp: icmp: icmp: icmp: icmp:

sparky sparky sparky sparky sparky

udp udp udp udp udp udp udp udp udp udp udp udp udp udp

port port port port port

32788 32791 32781 32787 32789

unreachable unreachable unreachable unreachable unreachable

(DF) (DF) (DF) (DF) (DF)

UD P Le n gt h Fie ld The UDP lengt h is t he num ber of byt es found in t he UDP header plus t he num ber of byt es found in t he UDP payload. The UDP header is 8 byt es so t he m inim um lengt h for t he UDP lengt h is 8 byt es. The m axim um t heoret ical byt e lengt h of an I P dat agram is 65535. Given t his, and t hat t he I P header is a m inim um of 20 byt es long, t he t heoret ical m axim um UDP lengt h value is 65515. Many UDP applicat ions lim it t he lengt h of t he UDP dat agram t o 8192 byt es, alt hough we saw where DNS lim it ed t he DNS payload t o 512 byt es. Also, t he TCP/ I P st ack of a given operat ing syst em as im plem ent ed in t he kernel m ight lim it t he lengt h of t he UDP dat agram .

I CM P I CMP is anot her prot ocol t hat is fairly sim ple as far as t he fields found in t he header. Like UDP, I CMP does not guarant ee delivery of t he m essage, so it s st ruct ure and fields are st raight forward. I CMP fields will be exam ined in t erm s of norm al and m alicious use. Type a n d Code Rem em ber t hat I CMP has no port s. There m ust be a m et hod indicat ing what t ype of I CMP m essage is being sent or received. The first t wo byt es of t he I CMP m essage are t he I CMP m essage t ype and code, respect ively. The m essage code is a subcat egory under t he m essage t ype. For inst ance, t here are t wo possible m essage codes for a m essage t ype of 11, which represent s t he t im e exceeded cat egory. I f t he m essage code is 0, it is a " t im e exceeded in- t ransit " m essage. I f t he m essage code is 1, it is an I P " reassem bly t im e exceeded" m essage.Valid values of I CMP m essage t ypes and codes are found at www.iana.org/ assignm ent s/ icm p- param et ers.

I de n t ifica t ion a n d Se qu e n ce N u m be r s I f you exam ine som e I CMP request s such as t he echo request , you'll find som e addit ional fields in t he I CMP header. These are t he I CMP ident ifier found in byt es 4 and 5 offset of t he I CMP header and t he I CMP sequence num ber found in byt es 6 and 7 offset of t he I CMP header. These fields are used in an echo request / echo reply pair t o uniquely ident ify request s and m at ch t hem wit h responses. For UNI X host s, t he I CMP I D is t ypically t he process I D of t he ping t hat generat ed t he t raffic. There can be several sim ult aneous ping com m ands so t he ident ifier in bot h t he echo request and echo reply inform s t he pinging host what reply is connect ed wit h what request . Each ping can generat e several echo request s and t he sequence num ber is t he m anner in which t hey are t racked in order t o see if t here are m issing packet s. Here is t he out put from a ping request t hat dem onst rat es t he change in I CMP sequence num bers.

PING sparky (1.1.1.100) from 1.1.1.5 : 56(84) bytes of data. 64 bytes from 1.1.1.100: icmp_seq=0 ttl=255 time=0.8 ms 64 bytes from 1.1.1.100: icmp_seq=1 ttl=255 time=0.9 ms 64 bytes from 1.1.1.100: icmp_seq=2 ttl=255 time=7.3 ms 16:33:07.400700 verbo > sparky: icmp: echo request 4500 0054 038d 0000 4001 bed1 0101 0105 0101 0164 0800 9e12 c402 0000 0391 8439 1d1d 0600 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 181916:33:07.401479 sparky > verbo: icmp: echo reply (DF) 4500 0054 010018f05 1d1d 0600 1415 1617

7146 4000 ff01 5217 010018f64 0000 a612 c402 0000 0391 8439 0809 0a0b 0c0d 0e0f 1011 1213 1819

Let 's exam ine t he I CMP ident ifier and sequence num bers in t he cont ext of t he previous out put 's ping. We ping host sparky from verbo and see from t he out put t hat t he sequence num ber begins at 0 and increm ent s for each new echo request sent out . I n t his case, t he ping process was abort ed aft er t he t hird echo request . I f you exam ine t he hex dum p, you'll see t hat t he ident ifier is a hex c402 or decim al 50178. Because t he pinging host is a Linux host , we assum e t his is t he process I D of t he ping. This value will rem ain st at ic for all echo request s and replies associat ed wit h t his ping. The sequence num ber, on t he ot her hand, will increase by 1 for each new echo request sent and will be cloned in t he associat ed echo reply. Had all t he echo request s and replies associat ed wit h t his ping process been displayed, we'd see four addit ional records, t wo echo request s, and t wo echo replies. The ident ifier would be t he sam e for all, but t he sequence num ber would

be 1 for t he second set of echo request s and replies, and it would be 2 for t he t hird set . M isu se of I CM P I de n t ifica t ion a n d Se qu e n ce N u m be r s

Because t he I CMP ident ifier and sequence num ber fields were not likely t o receive careful scrut iny in t he past , t hey were chosen t o signal exploit t raffic t o t he receiving host . I n t he case of t he a DDoS known as St acheldraht , t he I CMP ident ifier value of 667 was used t o init iat e connect ions bet ween handler and agent host s in an I CMP echo reply. The I CMP ident ifier value of 666 was used t o respond from agent t o handler wit h anot her I CMP echo reply. I n Tribe Flood Net work, an I CMP ident ifier value of 456 was used t o init iat e a connect ion bet ween client and daem on and a value of 123 was used t o respond—bot h using I CMP echo replies t oo. Finally, Loki of m any years ago had a st at ic hex value of 0xf001 or 0x01f0 in t he I CMP sequence num ber. These are all valid values for t hose fields so t uning a NI DS t o look solely for t hose values in t hose fields m ight generat e som e false posit ives. I t is best t o exam ine t hese packet s st at efully in t he cont ext in which t hey occurred.

Su m m a r y As we wind up our t wo- chapt er scrut iny of header fields in t he I P dat agram , we finish our exam inat ion of t he em bedded prot ocol fields. By far, TCP is t he busiest of t he prot ocol headers because of all of t he fields required t o m aint ain reliabilit y, st at e, order, and dat a flow cont rol. As you would im agine, t he init ial values select ed for som e of t hese fields prov ide a wealt h of inform at ion for nm ap operat ing syst em fingerprint ing scans. As well, som e of t he fields can be used for invasion or insert ion at t acks as we saw dem onst rat ed wit h t he TCP checksum exam ple in t he previous chapt er. UDP and I CMP header fields are uncom plicat ed in purpose. St ill, UDP port s can be scanned using nm ap by searching for port s for which no I CMP " port unreachable" m essage is ret urned. I CMP m essages can provide reconnaissance when allowed t o leave t he net work, and nm ap m akes use of exam ining t he em bedded m essages aft er t he I CMP header t o ident ify rem ot e operat ing syst em s. Finally, t he I CMP ident ificat ion and sequence num bers have been used for st ealt hy purposes in DDoS at t acks or covert prot ocol exchanges.

Ch a pt e r 1 0 . Re a l- W or ld An a lysis

No doubt you've had your fill of healt hy, low- fat t heory on packet dissect ion and header fields. How about bringing on som e of t he m ore int erest ing, t ast y, realworld t raffic? That is what we are about t o em bark on in t his chapt er. For you t o underst and t he analysis t hat will be shown here, it was necessary t o lay t he groundwork in previous chapt ers first . To refresh your m em ory of t he int ent of t his sect ion, we want t o analyze t raffic from m any different viewpoint s. We've evolved from bit s and fields in previous chapt ers t o inspect ing one or m ore packet s for t heir int ent and explaining som e act ual event s of int erest t hat were capt ured by Shadow from sit es. The t ransit ion from underst anding t heory t o act ually explaining som e t raffic t hat you see is not necessarily an easy or int uit ive one. I t t akes t im e and exposure t o som e int erest ing t raffic before you gain t he confidence and experience t o m ake t his t ransit ion. The exam ples shown in t his chapt er should help you get st art ed.

You 've Be e n H a ck e d! The sim plicit y of t his first real- world event belies it s poignancy. I n a form er lifet im e, I worked for a local m ilit ary Com put er Em ergency Response Team ( CERT) . I worked an early shift beginning about 5: 30 A.M. t o avoid t he brunt of t he rush hour t raffic from t he suburbs of one of t he nat ion's m ost awful com m ut ing cit ies, Washingt on, DC. I walked int o t he office one m orning, and t he phone was already ringing—not a good sign unless it is Ed McMahon calling t o t ell m e I 'd won t he Publisher's Clearinghouse Sweepst akes. I nst ead, t he call was from one of our parent m ilit ary CERTs inform ing us t hat we'd had a break- in over night . As a bit of background, t he parent CERT used a different set of t ools t o m onit or our sit e t han we did, and would som et im es call when it had an inquiry about t raffic or t o report som et hing not ewort hy, as in t his case. The CERT supplied t he dat e,

approxim at e t im e, and source and dest inat ion I Ps associat ed wit h t he break- in, but could supply no m ore inform at ion t han t his when queried. The dest inat ion I P of t he alleged vict im host was a DNS server at t he sit e. This was probably one of t he best m aint ained host s on t he sit e; it had t he m ost recent pat ches of BI ND, it had all port s closed except for secure shell ( SSH) from specific source addresses and DNS queries, and it had been st ripped of all unnecessary user account s. I t was not as if t his was som e legacy syst em sit t ing openly on a DMZ wit h no recent at t ent ion, superfluous port s open, and unrest rict ed access. St ill, alt hough m y first react ion was skept icism , I wasn't naive enough t o t hink t hat any host connect ed t o t he I nt ernet was im pervious t o at t ack. Aft er all, t his was a DNS server, and t he venerable BI ND soft ware has been plagued wit h a hist ory of problem s, including buffer overflow at t acks t hat allowed rem ot e root access. A rat ional way t o approach t his early m orning report was t o use TCPdum p records from Shadow t o exam ine all t raffic t o and from our DNS server from t he alleged at t acker's I P address. Before showing you an excerpt of t he result s of t hat , let 's j ust re- exam ine what an est ablished TCP session looks like in t erm s of TCPdum p. Th r e e - W a y H a n dsh a k e :

boulder.myplace.com.38060 > aspen.myplace.com.telnet: S 3774957990: 3774957990(0) win 8760 (DF) aspen.myplace.com.telnet > boulder.myplace.com.38060: S 2009600000: 2009600000(0) ack 3774957991 win 1024 boulder.myplace.com.38060 > aspen.myplace.com.telnet:. ack 1 win 8760 (DF)

D a t a Ex ch a n ge :

boulder.myplace.com.38060 > aspen.myplace.com.telnet: P 1:28(27) ack 1 win 8760 (DF) aspen.myplace.com.telnet > boulder.myplace.com.38060: P 1:14(13) ack 1 win 1024 aspen.myplace.com.telnet > boulder.myplace.com.38060: P 14:23(9) ack 28 win 1024

Se ssion Te r m in a t ion :

aspen.myplace.com.telnet > boulder.myplace.com.38060: win 1024 boulder.myplace.com.38060 > aspen.myplace.com.telnet: boulder.myplace.com.38060 > aspen.myplace.com.telnet: win 8760(DF) aspen.myplace.com.telnet > boulder.myplace.com.38060:

F 4289:4289(0) ack 92 .ack 4290 win 8760 (DF) F 92:92(0) ack 4290 .ack 93 win 1024

First , for t wo host s t o exchange som e kind of dat a, t hey have t o com plet e t he t hree- way handshake. I n t his case, we have host boulder.myplace.com request ing t o connect t o host aspen.myplace.com on port t elnet . Host aspen.myplace.com offers t elnet service; and t he t wo host s synchronize sequence num bers and t he connect ion is est ablished. Next , t ypically a client connect s t o a host for t he purpose of exchanging som e dat a. And in t his case, we wit ness t he exchange bet ween bot h host s as we see 27, 13, and 9 byt es of dat a sent respect ively in t he t hree PUSH packet s displayed. More dat a was exchanged before t he session was t erm inat ed, but t hat is not shown because it really adds no new insight int o t his discussion. Finally, t he t wo host s gracefully sever t he connect ion by exchanging and acknowledging FI N packet s. That is what norm al TCP sessions look like. Now, exam ine som e of t he t raffic from t he alleged break- in:

whatsup.net.24997 > 512 whatsup.net.25002 >

whatsup.net.25075 >

dns.myplace.com.ftp whatsup.net.25177 >

whatsup.net.25189 >

whatsup.net.25118 > 512

dns.myplace.com.sunrpc: S 2368718861:2368718861(0) win dns.myplace.com.139: S 4067302570:4067302570(0) win 512 dns.myplace.com.ftp: S 1368714289:1368714289(0) win 512 > whatsup.net.25075: R 0:0(0) ack 1368714290 win 0 (DF) dns.myplace.com.1114: S 3231175487:3231175487(0) win 512 dns.myplace.com.tcpmux: S 368146356:368146356(0) win 512 dns.myplace.com.22: S 2035824356:2035824356(0)

win

The m alicious host is whatsup.net and our DNS server is dns.myplace.com. We see a bunch of at t em pt ed SYN connect ions t o various different port s st aring wit h port 111, also known as sunrpc or port m apper, port 139, Net BI OS session m anager, ft p, and so on. We see no response from t he DNS server except t o ret urn a RESET on t he ft p query. We can surm ise t hat t he packet - filt ering device blocked t he ot her port s we see, yet not ft p. When t he DNS server received t he ft p SYN at t em pt , it responded wit h a RESET because it didn't list en at t hat port . This is j ust an excerpt of t he t raffic seen, yet it all was sim ilar except for t he different dest inat ion port s at t em pt ed. The point is t hat t here were no successful t hree- way handshakes, dat a exchange, or session t erm inat ions wit nessed. Unless t here was som e kind of unknown backdoor int o our net work t hat was not m onit ored, it appears t hat t his was a sim ple scan of t he DNS server and not a break- in. Aft er analyzing t his t raffic, I called t he person who had report ed t he break- in. I shared m y result s and asked what kind of evidence t hey had t hat t here was a

break- in. The person replied t hat one of t heir parent CERT organizat ions had report ed t his and was j ust passing t he inform at ion on t o our sit e. I got t he cont act inform at ion for t he original person who report ed t he incident and called t o inquire why he believed we had suffered an int rusion. The response was t hat he had report ed it as a scan, and it had been m ist akenly com m unicat ed t o m e as a breakin. My m ission had not been t o det erm ine culpabilit y; it was t o det erm ine what kind of solid evidence anyone had t o refut e m y belief t hat we had only had a scan. But , as it t urned out , t here really was no break- in aft er all. This incident brought hom e t he necessit y for having an audit t rail of act ivit y int o and out of t he net work. Had we not had t he TCPdum p records of t he scan, we would have had no evidence t o refut e t he int rusion claim . We would have had t o t rust t he caller and believe t hat we had an int rusion t hat none of our NI DS had det ect ed. We could have logged on t o t he DNS server. Yet , t here would be an absence of any evidence, if we were lucky. There would be no changes in any of t he Tripwire logs t hat m aint ained int egrit y audit s of im port ant files, t here would be no root kit s, and t here would be no changes t o password files or inet d st art up files. I t would be im possible t o know for cert ain t hat t here had been no int rusion; t here would be lingering doubt t hat we j ust were not seeing t he m anifest at ions of t he break- in, perhaps because of inst alled root kit s and Troj aned soft ware. I n such a case where you are st ill uncert ain about t he healt h of t he host , t here are not a lot of opt ions. You have t o rebuild t he syst em from t he ground up—not a desirable t ask. Prior t o t his event , I had been a proponent of Shadow and had been collect ing TCPdum p act ivit y at m onit ored sit es. This convert ed m e t o a die- hard Shadow user, and I now use Shadow for all sit es t hat I m onit or. Trut hfully, it doesn't m at t er if you use TCPdum p or any ot her collect ion m echanism . What m at t ers is t hat you have t his hist orical capt ure of t he t raffic ent ering and leaving your net work. And, you don't need t o capt ure payload, j ust t he header port ions of t he records, t o underst and t he nat ure of t he act ivit y as was dem onst rat ed in t his incident . I ndeed, it also can be helpful t o capt ure payload if you have enough space, even if only t o keep it a couple of days before archiving it .

N e t bu s Sca n I n t he next incident , we exam ine a scan t o dest inat ion port 12345, which is t ypically associat ed wit h t he net bus Troj an t hat affect s Windows host s. This part icular scan was launched against a Class B subnet so t hat it set off all kinds of alarm s. The net work t hat was scanned had som e high- num bered port access open t hrough t he packet - filt ering devices. The following records provide a very brief excerpt of t he det ect ed t raffic. This scan

at t em pt ed connect ions t o m ore t han 65,000 I Ps in t he t arget net work. I t is im port ant t o not e t hat t his t raffic was collect ed on a sensor locat ed behind ( inside) t he packet - filt ering device. This is t he t raffic t hat act ually got inside t he net work. Scans happen! I n fact , t hey happen all t he t im e on t his part icular net work. I t 's not t hat t his net work is any m ore invit ing t han ot hers; it is j ust a fact of life t hat scanning is inevit able and frequent . Knowing t his, you cannot get t oo worked up when you see scans. However, t his is inside t he packet - filt ering device m aking it m ore t han a curiosit y, as we will lat er see. Here are t he records:

bigscan.net.1737 > 192.168.7.0.12345: S 2299794832:2299794832(0) win 32120 (DF) bigscan.net.1739 > 192.168.7.2.12345: S 2299202490:2299202490(0) win 32120 (DF) bigscan.net.1741 > 192.168.7.4.12345: S 2293163750:2293163750(0) win 32120 (DF) bigscan.net.1743 > 192.168.7.6.12345: S 2298524651:2298524651(0) win 32120 (DF) bigscan.net.1745 > 192.168.7.8.12345: S 2297131917:2297131917(0) win 32120 (DF) bigscan.net.1747 > 192.168.7.10.12345: S 2291750743:2291750743(0) win 32120 (DF) bigscan.net.1749 > 192.168.7.12.12345: S 2287868521:2287868521(0) win 32120 (DF

We see t he scanning host bigscan.net m et hodically m oving t hrough t he 192.168.7 subnet wit h a unique scan search pat t ern of looking at t he .0 address and even final oct et s t hereaft er.

N e t bu s H ij in k s Net bus is a t ool t hat allows rem ot e access and cont rol of a Windows host . Aft er a host is com prom ised, it behooves t he at t acker t o have a m eans of fut ure access t o t he host . Net bus is one of m any backdoor Troj ans t hat can be run t o provide st ealt hy access. I t predat es anot her, m ore fam iliar backdoor Troj an, Back Orifice. Bot h Net bus and Back Orifice have userfriendly GUI int erfaces t o easily cont rol t he rem ot e com prom ised host .

N ot All Th a t Ru n s on Por t 1 2 3 4 5 I s M a liciou s

The OfficeScan virus eradicat ion package for t he corporat e ent erprise list ens on TCP port 12345 on t he deskt op host . The ent erprise soft ware accom m odat es cent ral virus report ing, aut om at ic updat e ( apparent ly via port 12345 on t he updat ed host ) , and rem ot e m anagem ent for ease of use t o assist in m onit oring and configurat ion. I f you ever see a host t hat list ens on TCP port 12345, it is possible t hat it m ight be a helpful rat her t han harm ful process. Given t he range of possible list ening port s 1 t hrough 65535, I 'd m uch prefer t o see t he whit e hat s ( good guys) select list ening port s t hat don't share com m only used hacker port s. Let 's go for t he j ugular and see if t here is any need t o furt her invest igat e t his scan. We want t o exam ine t he host s in t he int ernal net work and see if t hey responded t o t he scan. The TCPdum p filt er t o exam ine t his would look for t raffic from t he int ernal net work of 192.168 wit h a source port of 12345 and a TCP flag pair of SYN and ACK. This m eans t hat we have a list ening host , which can be pot ent ially very dangerous. Our filt er could have used t he I P num ber of t he scanning host inst ead of or in conj unct ion wit h t he int ernal subnet address. The TCPdum p com m and used t o ext ract response records associat ed wit h t he scan reads from t he binary file of collect ed records for t he sit e, and ident ifies t his scan as one t hat involved t he int ernal 192.168 subnet and port 12345. The TCPdum p com m and is furt her refined by using a filt er t hat looks at t he 13 t h byt e offset of t he TCP header, where t he TCP flag byt e is locat ed, and looks for t he ACK flag and t he SYN flag set sim ult aneously. Here is t he TCPdum p com m and and t he out put generat ed from it :

tcpdump -r tcpdumpfile 'net 192.168 and port 12345 and tcp[13] = 0x12' mynet.edu.12345 > bigscan.net.3698: S 2633608519:2633608519(0) ack 2346088305 win 49152 (DF)

The good news is t hat only one host responded. The bad news is t hat one host responded! When it was discovered t hat t here was a responding host , t his incident was escalat ed t o t he highest priorit y because we believed we had a host offering t he net bus Troj an, a nat ural conclusion. The scan and subsequent discovery t hat t here was a responding host occurred by 7: 00 A.M., m eaning t hat m ost of t he st aff had not yet arrived at work. I n t he int erim , t he net work group was cont act ed and t old t o disallow any inbound or out bound t raffic t o or from t he responding host by blocking it at t he packet - filt ering device. Also, t he local com put er incident response t eam was m obilized t o scan t he host for vulnerabilit ies and t rack down t he owner. Aft er som e superficial probing, t he incident response t eam discovered t hat t he

host was a Silicon Graphics, I nc. ( SGI ) running an older version of I rix ( SGI 's version of UNI X) . As a vet eran of incident response t eam s, I rem em bered t hat older versions of I rix used t o com e configured wit h an account of lp ( line print er) wit h no password. Tragically, a t elnet connect ion t o t he host allowed m e access t o t he host , using t he lp account and no password. This discovery pret t y m uch ruled out t hat t his was a net bus problem because t he responding host ran a version of UNI X, but we did have a rogue port answering and a host t hat had lit t le, if any, securit y. Concurrent ly, t he search for t he host 's syst em adm inist rat ors cont inued. Ownership records were dat ed and t he host had been t ossed from adm inist rat or t o adm inist rat or as people m oved in and out of t he organizat ion and assignm ent s changed. This part icular host had a rich hist ory of neglect because t he useradm inist rat ors were scient ist s or engineers who were never really t rained in adm inist rat ion, let alone securit y. This is a com m on paradigm of neglect because m any research depart m ent s do not have t he budget t o hire t rained adm inist rat ors. The users are usually overburdened workers who j ust need t o keep t he host running. The syst em adm inist rat ors of t he SGI host s finally arrived at work. As suspect ed, t hey had no idea what was list ening on port 12345. I t was also quit e apparent t hat t hey and t heir users had lit t le concern or appreciat ion for securit y. We t old t hem it was necessary t o disconnect t he host from t he net work and begin backups for forensic purposes. An argum ent ensued when one of t he users becam e indignant about needing t o have t he host up and accessible on t he net work. The leader of t he incident response t eam polit ely t old him t hat he had t wo opt ions: first , t o cooperat e and willingly cede cont rol, or second, t o have t he net work connect ion uncerem oniously severed by wire cut t ers. I t seem s t he light bulb went on at t hat point , and t hey agreed t o cooperat e. When we finally got access t o t he syst em , we want ed t o m ake sure t hat t he host was list ening on port 12345. The process of m aking backups on t his host was long and cum bersom e, so we didn't want t o m ake t hem do anyt hing unnecessary. At t he sam e t im e, we didn't want t o ruin any forensic evidence by poking around t oo m uch. Only one com m and was at t em pt ed—t he net st at –a com m and t o m ake sure t hat port 12345 was running. Can you see t he flaw of execut ing t he net st at com m and? I n hindsight , it seem s t his was really not such a wise m ove. Had t he net st at com m and report ed t hat port 12345 was not list ening, t his would have been ext rem ely suspicious and m ore indicat ive of a Troj aned or root kit net st at program running on t he host t hat was alt ered t o not report t hat port 12345 was list ening. But , t his was not t he case; port 12345 was list ening. Syst em backups were st art ed t o preserve any forensic evidence in case som e kind of prosecut ion ever had t o be done. Finally, when t he backups were com plet ed, we had an opport unit y t o exam ine t he syst em . We didn't want t o dist urb it in any way

prior t o t he backups. A very handy com m and in t his sit uat ion is t he fuser com m and. This is not available for all UNI X operat ing syst em s, but it is available on I rix and Linux:

[root@irix]# 12345/tcp:

fuser 12345/tcp 490

The com m and was issued t o find t he process num ber associat ed wit h port 12345 on TCP. By looking at t he net st at out put , you don't know t he process t hat is running t he service on port 12345. The fuser com m and ret urns t he process num ber of t he soft ware running on t hat port . Next , you have t o find what t hat part icular process num ber is running. That can be done using t he ps com m and and t hen exam ining t he out put for t he process num ber, in t his case 490:

[root@irix]# ps -ef | grep 490 root 490 483 0 Sep19 ? 00:02:17 /usr/local/bin/license_manager

You see t hat t here is a license m anager running. When t his appeared on t he console wit h t he syst em adm inist rat or wat ching, he rem arked t hat he had recent ly inst alled a license m anager. He had no idea what port it list ened on. The m yst ery was solved! This was t he best possible resolut ion considering t he alt ernat ives. But , give m e a break—what reput able license m anager soft ware m aker would use a default list ening port of 12345? Before t his host was allowed back on t he net work, it was cleaned up wit h t he assist ance of a savvy UNI X adm inist rat or. An init ial vulnerabilit y scan of t he host produced about t went y pages of high- and m edium - range securit y problem s. I t was scanned again aft er t he changes and upgrades t o m ake sure t hat no known vulnerabilit ies exist ed.

Ot h e r Com m a n ds t o D ispla y Pr ogr a m s Associa t e d w it h Por t s The UNI X com m and lsof can be used, as well, t o list inform at ion about files opened by processes. This com es wit h m any UNI X operat ing syst em s, but can be downloaded and added if it is not available. To find t he process I D associat ed wit h t he service list ening on port 901 using lsof, execut e t he following:

lsof -i TCP:901 COMMAND PID USER inetd 387 root

FD 9u

TYPE DEVICE SIZE NODE NAME IPv4 369 TCP *:swat (LISTEN)

You see t hat port 901 is associat ed wit h t he inet d process. This is t he I nt ernet daem on t hat st art s m ost of t he list ening services. Som e addit ional inform at ion is displayed in t he last colum n; port 901 is associat ed wit h Sam ba Web Adm inist rat ion Tool ( swat ) . You should find t his st art ed in t he file / et c/ inet d.conf:

grep swat /etc/inetd.conf swat stream tcp nowait.400

root /usr/sbin/swat swat

A Windows t ool known as fport ( available wit h a t ool search on ht t p: / / www.securit yfocus.com / ) can be used t o associat e processes wit h port s on which t hey run. Here is a sam ple out put from running fport on a Windows 2000 host :

FPort v1.31 - TCP/IP Process to Port Mapper Copyright 2000 by Foundstone, Inc. http://www.foundstone.com Securing the dot com world Pid Process Port Proto Path 384 svchost -> 135 TCP C:\WINNT\system32\svchost.exe 8 System -> 445 TCP 496 MSTask -> 1025 TCP C:\WINNT\system32\MSTask.exe 8 System -> 1027 TCP 1692 SshClient -> 3705 TCP C:\Program Files\SSH Communications Security\SSH Secure Shell\SshClient.exe 1892 OUTLOOK -> 4040 TCP C:\Program Files\Microsoft Office\Office\OUTLOOK.EXE 384 svchost -> 135 8 System -> 445 220 services -> 1026 916 iexplore -> 1341 Explorer\iexplore.exe 1892 OUTLOOK -> 4024 Office\Office\OUTLOOK.EXE

UDP UDP UDP UDP

C:\WINNT\system32\svchost.exe

UDP

C:\Program Files\Microsoft

C:\WINNT\system32\services.exe C:\Program Files\Internet

Alt hough t his t urned out t o be a non- incident in t erm s of int rusions, it does

illust rat e a very not ewort hy point . I t is ext rem ely helpful t o be able t o do a quick assessm ent of pot ent ial reconnaissance or pot ent ial dam age from scan act ivit y of your net work. Most NI DS report about scans, not ifying you t hat t hey have occurred. But , t he m ore relevant knowledge is t his: did any host respond t o t he scans? That is where TCPdum p recorded act ivit y is once again invaluable.

H ow Slow Ca n you Go? This event concerns a rem ot ely m onit ored sit e t hat had poor response t im e on a good day. One day while at t em pt ing t o exam ine act ivit y, t he response t im e becam e painfully slow. I t was so slow, you could t ype in one charact er and it would t ake about 30 seconds t o see it echoed back on t he screen. This was pret t y annoying, but signaled t hat t he sit e had som e issues ot her t han norm al poor response t im e. Alt hough t his was occurring, we were collect ing a copy of t heir Shadow sensor dat a at our sit e. I n an at t em pt t o explain t he poor response t im e, t he sit e's Shadow event s of int erest were exam ined. I t showed t hat t hey were get t ing a lot of fragm ent ed act ivit y direct ed at t heir net work address of 192.168.133.0 ( t his is a t ranslat ed address for anonym it y purposes) . Upon furt her exam inat ion, it was discovered t hat t his had been going on for m any hours. Here is a sam ple of t he records t hat t hey were get t ing:

12:01:12.150572 12:01:17.560572 12:01:17.570572 12:01:22.200572 12:01:22.210572 12:01:22.220572 12:01:22.230572 12:01:27.240572 12:01:27.250572 12:01:37.230572 12:01:37.240572 12:01:37.240572 12:01:37.250572 12:01:42.300572

dos.com dos.com dos.com dos.com dos.com dos.com dos.com dos.com dos.com dos.com dos.com dos.com dos.com dos.com

> > > > > > > > > > > > > >

192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0: 192.168.133.0:

(frag (frag (frag (frag (frag (frag (frag (frag (frag (frag (frag (frag (frag (frag

54050:1480@4440+) 54050:1480@2960+) 54050:1480@4440+) 54050:1480@1480+) 54050:1480@2960+) 54050:1480@4440+) 54050:1480@5920+) 54050:1480@2960+) 54050:1480@5920+) 54050:1480@1480+) 54050:1480@2960+) 54050:1480@4440+) 54050:1480@5920+) 54050:1480@1480+)

You see dos.com sending fragm ent ed packet s t o t he net work address. As m ent ioned, t his act ivit y had been happening for several hours. There are a couple of problem s wit h t he t raffic t hat need t o be exam ined. See if you can find t he t hree problem s associat ed wit h fragm ent at ion in t he previous TCPdum p out put . First , a norm al fragm ent ed packet t rain usually has t wo or m ore part s: z

There is an init ial fragm ent t hat has an offset of 0 and t he More Fragm ent s flag set ( + ) :

frag 54050:1480@0+

Recall t hat t he fragm ent form at is as follows:

frag FRAG-ID:BYTES-IN-CURRENT-FRAGMENT@OFFSET-INTO-FRAGMENT-DATA [+]

z

z

There m ight be int erm ediat e fragm ent s t hat are neit her t he first nor last fragm ent s. An int erm ediat e fragm ent has a non- zero offset and t he More Fragm ent s flag set . The + flag indicat es t hat t he m ore fragm ent s bit is set or t here is anot her fragm ent following t he one being sent . The More Fragm ent s flag is set in t he first and int erm ediat e fragm ent s. There is a final fragm ent , one in which t he m ore fragm ent s bit is not set : no + flag.

This act ivit y appeared on Shadow's hourly wrap- up from t he default because bot h t he fragm ent at ion and t he dest inat ion address having a final oct et of 0 ( t he net work address 192.168.133.0) . The fragm ent at ion t hat is seen in t his log has som e definit e problem s: 1 . There is no first fragm ent —one t hat has an offset of 0. 2 . You see repeat ed offset s for fragm ent s t hat are in t he sam e fragm ent t rain wit h t he fragm ent I D of 54050. For inst ance, t he fragm ent offset 4440 is repeat ed several t im es. 3 . There is no final fragm ent —one t hat doesn't have t he More Fragm ent s flag ( + ) set . I t is possible t hat t he offset values are not chronological because t he fragm ent s don't necessarily arrive in t he order in which t hey were sent . Aft er doing som e research about t he t opology of t he rem ot e sit e, we discovered t hat our sensor was locat ed behind ( inside) a packet - filt ering device t hat blocked inbound I CMP echo request s. That is t he reason we believe t hat t he init ial fragm ent was never seen. Keep in m ind t hat only t he first fragm ent in t he fragm ent t rain carries t he em bedded prot ocol header, such as t he inform at ion t o say t hat t hese packet s were associat ed wit h I CMP echo request s. We can only surm ise t hat t he fragm ent ed act ivit y was associat ed wit h t he dropped I CMP echo

request s. The packet - filt ering device t hat blocked t his act ivit y was a rout er t hat did not keep t rack of st at e. Therefore, it blocked t he first fragm ent of t he fragm ent t rain because it was t he one t hat cont ained t he inform at ion t hat t his was an I CMP echo request . The rout er had no m eans of associat ing t he first fragm ent wit h subsequent ones. I t appears obvious t o us t hat t he subsequent packet s all share t he sam e fragm ent I D and are assum ed t o be associat ed wit h t he blocked one. Yet , t his rout er did not m aint ain t hat inform at ion and allowed t he subsequent fragm ent s int o t he net work. However, t his doesn't explain why no final fragm ent was observed. This should have not hing t o do wit h a rout er t hat is incapable of keeping t rack of st at e. The only explanat ion for not receiving a final fragm ent is t hat is was int ent ionally om it t ed. Norm ally, fragm ent s are reassem bled by t he dest inat ion host only and not by int erm ediat e rout ers t hrough which t hey t ravel. However, in t his case, t he rout er at t em pt s t o reassem ble t he fragm ent ed packet s because t hey are sent t o t he net work address 192.168.133.0 on which t he rout er resides. This part icular rout er has an old Berkeley Soft ware Dist ribut ion ( BSD) TCP/ I P st yle st ack t hat responds t o t his " broadcast " so t hat it at t em pt s t o reassem ble t he fragm ent s. The rout er has lim it ed cache for reassem bly. The com binat ion of t he repet it ion of t he sam e fragm ent I D, t he m ore fragm ent s bit set in every fragm ent , and t he m issing first and last fragm ent s severely encum bered t he rout er so t hat it couldn't do rout ing work. The rout er would never t im e out on reassem bly of t hese packet s because it kept seeing evidence t hat m ore fragm ent s were com ing. This was a successful denial of service ( DoS) against t he rout er. When t he host ile I P was blocked on an ext ernal rout er, t he response t im e ret urned t o norm al. Why didn't t his rout er expire t he incom plet e set of fragm ent s wit h an I CMP " I P reassem bly t im e exceeded" m essage? Aft er all, isn't t his a prim e candidat e for resource exhaust ion, wait ing for a fragm ent or fragm ent s t hat are never sent ? The problem is t hat for t he " I P reassem bly t im e exceeded" m essage t o be delivered and for t he receiving host t o expire t he fragm ent s, t he first fragm ent m ust be received. Because t he out erm ost rout er blocked t hese, t he first fragm ent never arrived, and ot hers could not be expired. Alt hough som e rout ers block incom ing I CMP echo request s, denial of service at t acks against t he rout er should not occur for " norm al" t raffic. The DoS at t ack succeeded against t his part icular rout er because of t he broadcast address, t he repeat ed fragm ent I D, and t he m issing fragm ent s. Aft er t he problem was discovered, t he act ivit y was blocked from t he host ile source I P address. This blocked all inbound t raffic including fragm ent s because t he I P address is repeat ed in each of t he I P headers of every fragm ent .

This was successful, and t he response t im e ret urned t o it s norm al slow ( but not painful) st at e. The at t ackers m ust have sensed t his; chances are t hat t he m onit ored sit e m ust have foolishly sent I CMP errors t hat indicat ed t hat t heir act ivit y was blocked. The at t ackers responded by at t em pt ing t he sam e at t ack wit h a different source I P address on t he sam e subnet .

Ex pla n a t ion Ack n ow le dge m e n t a n d Addit ion a l Re fe r e n ce Many t hanks and m uch credit t o Vicki I rwin of t he SANS I nst it ut e for her assist ance in figuring out t he rout er DoS. She referenced t he following for a discussion of t his and sim ilar exploit s: www.cisco.com / warp/ public/ 770/ nifrag.sht m l

Rin gZe r o W or m Let 's wrap up our foray int o real- world analysis by exam ining t he RingZero Worm . This worm would probably be considered ancient in I nt ernet t im e because it was discovered in t he lat t er part of 1999. Plent y has t ranspired concerning m alicious code since t hat t im e, yet som e of t he concept s t hat can be learned from exam inat ion of t he worm act ivit y are t im eless. This present s a good t ransit ion int o t he next and final chapt er of t his sect ion t hat delves m ore deeply int o forensics. The first indicat ion t hat t he m onit ored sit e had som e new and unusual act ivit y was t hat Shadow report ed m any different at t em pt s t o connect t o TCP port 3128, t he squid web proxy server. These at t em pt ed connect ions occurred m any t im es an hour and were from source host s from all over t he world. Alt hough it has becom e rat her com m onplace t oday wit h m alicious code such as Code Red and nim da t o see m any different source I Ps scanning m any different dest inat ion I Ps, in lat e 1999, it was a rarit y. Here is an excerpt of t he kind of act ivit y seen for one hour at t he m onit ored sit e:

12:29:48.230000 8192 12:29:58.070000 8192 12:30:10.960000 8192

4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win (DF) 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win (DF) 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win (DF)

12:44:54.960000 1.2.3.4.3243 win 8192 (DF) 12:44:57.930000 1.2.3.4.3243 win 8192 (DF) 12:45:03.930000 1.2.3.4.3243 win 8192 (DF) 12:45:15.930000 1.2.3.4.3243 win 8192 (DF)

> 172.16.187.212.3128: S 356330349:356330349(0) > 172.16.187.212.3128: S 356330349:356330349(0) > 172.16.187.212.3128: S 356330349:356330349(0) > 172.16.187.212.3128: S 356330349:356330349(0)

12:46:13.070000 1.1.1.1.2262 > 8192 12:46:16.080000 1.1.1.1.2262 > 8192 12:46:22.070000 1.1.1.1.2262 > 8192

172.16.99.110.3128: S 20315949:20315949(0) win (DF) 172.16.99.110.3128: S 20315949:20315949(0) win (DF) 172.16.99.110.3128: S 20315949:20315949(0) win (DF)

Three different source I Ps—4.3.2.1, 1.2.3.4, and 1.1.1.1—are at t em pt ing connect ions t o t hree different int ernal dest inat ion I P addresses. Because m any of t he scanned dest inat ion I Ps in our net work were not act ive, t here appeared t o be no prior reconnaissance t hat would t arget live host s only. Each source host ret ries ( source port s and TCP sequence num bers do not change) t he connect ion several t im es because t he dest inat ion host s do not respond, and no I CMP error m essage is ret urned t o indicat e t hat t he dest inat ion host s are unreachable. Looking at t he t im est am ps, you can see t hat t hese connect ion at t em pt s occurred at different t im es during t he 12: 00 hour. Our sit e was not t he only one t hat wit nessed t his act ivit y; t he Naval Surface Warfare Cent er was also seeing t hese scans as well as ones t o dest inat ion port 80 and 8080. Ot her sit es wit nessed t his act ivit y, and soon, it becam e apparent t hat t his act ivit y was very widespread. The init ial assessm ent of t he act ivit y was som eone at t em pt ing t o find open web proxy servers. Open proxy servers som et im es offer a " t unnel" t hrough which a hacker can gain access and assum e t he source I P of t he proxy t o hide his t racks. At t his point , because t he t raffic was com ing from all over t he world, one t heory was t hat t he source I Ps had been spoofed and it was j ust a handful of host s involved. Again, t his at t ack pre- dat es t he not ion of dist ribut ed denial of service ( DDoS) at t acks, so we were unaccust om ed t o dealing wit h m any source host s t o m any dest inat ion host at t acks. The verbose opt ion ( - vv) of TCPdum p m ight provide som e assist ance in det erm ining whet her or not t he source I Ps were spoofed. The sam e TCPdum p records are exam ined again, but t his t im e using t he verbose opt ion:

12:29:48.230000 8192 12:29:58.070000 8192 12:30:10.960000 8192

4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win (DF) (ttl 19, id 9072) 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win (DF) (ttl 19, id 29552) 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win (DF) (ttl 19, id 39792)

12:44:54.960000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192 (DF) (ttl 19, id 962) 12:44:57.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192 (DF) (ttl 19, id 11714) 12:45:03.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192 (DF) (ttl 19, id 22466)

12:45:15.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192 (DF) (ttl 19, id 33218) 12:46:13.070000 1.1.1.1.2262 > 8192 12:46:16.080000 1.1.1.1.2262 > 8192 12:46:22.070000 1.1.1.1.2262 > 8192 12:46:34.080000 1.1.1.1.2262 > 8192

172.16.99.110.3128: S 20315949:20315949(0) (DF) (ttl 116, id 35676) 172.16.99.110.3128: S 20315949:20315949(0) (DF) (ttl 116, id 46428) 172.16.99.110.3128: S 20315949:20315949(0) (DF) (ttl 116, id 57180) 172.16.99.110.3128: S 20315949:20315949(0) (DF) (ttl 116, id 2397)

win win win win

Let 's scrut inize t hese records, but t his t im e in t erm s of source I P spoofing. The salient advice t o rem em ber when looking for spoofed source I Ps is t o look for sim ilarit ies in t he fields or charact erist ics of packet s. More likely t han not , an at t acker will not t ake t im e t o " craft " in differences in t he packet s, and t here will be som e t races of unlikely sim ilarit ies. Conversely, when dist inct source I Ps t ruly represent different source host s, differences in packet charact erist ics should be apparent . Given t his knowledge, what differences can you find am ong t he t hree different source I Ps of t he previously shown t raffic? For st art ers, you pret t y m uch have t o do fourt h- down- and- punt wit h t he I P ident ificat ion num bers. The t im e gaps bet ween when each set of init ial connect ions received is t oo great t o see real t rends in I P ident ificat ion num bers. Ten m inut es pass bet ween t he first and second set of connect ions, which is enough t im e for t he I P ident ificat ion num bers of a busy host t o go t hrough all 65,535 num bers and wrap.You would ordinarily look for a chronology of very close I P ident ificat ion num bers, which would indicat e source I P spoofing. But , t his can only be done if t he t im e changes are insignificant . What about t he arriving TTL values? They look prom ising for spoofing because bot h t he first t wo set s of connect ions involving source I Ps of 1.2.3.4 and 4.3.2.1 have an arriving TTL value of 19. However, t he t hird set from 1.1.1.1 has an arriving TTL value of 116. Are t here any ot her differences? Look at t he TCP opt ions for t he connect ions. The first t wo source I Ps share t he sam e TCP opt ions, a m axim um segm ent size ( m ss) of 1460.Yet , t he t hird source I P also has a select ive acknowledgem ent ( sackOK) t hat m ust be padded wit h t wo noop's t o fall on a 4- byt e boundary. Finally, look at t he num ber of ret ries per at t em pt ed connect ion and t he backoff t im e bet ween init ial t ries and ret ries and bet ween subsequent ret ries. The first source I P 4.3.2.1 has an init ial t ry and t wo ret ries. The backoff t im e bet ween ret ries is approxim at ely 10 seconds. Next , I P 1.2.3.4 has one init ial t ry and t hree ret ries wit h t he ret ry at t em pt s doubling in t he am ount of t im e before subsequent ones. Finally, t he source I P 1.1.1.1 behaves m uch like 1.2.3.4 as far as ret ries in t hat it has t hree ret ries wit h a doubling of t he backoff t im e. From all t he forensics from t he preceding dum p, we can pret t y m uch conclude t hat t hese are act ual separat e source I Ps.

When t he t raffic was observed, we t ook t he TTL values, est im at ed t he init ial TTL values, and subt ract ed t he arriving from t he init ial values. This gave us t he num ber of hop count s t hat t he dat agram t ook t o arrive on t he sensor net work. Then, we execut ed a t racerout e back t o t he source I P t o see if t he expect ed hop count was close t o t he act ual hop count . About a dozen t racerout es were at t em pt ed; m ost had a hop count credibly close t o t he act ual hop count . Also, all t he t arget ed I Ps were alive, which m ight not be t he case had random I Ps been chosen for spoofing. I t would be rare if som eone were doing m ass am ount s of spoofing using hand picked live I P num bers only. Usually, it is a far m ore random select ion of spoofed source I P num bers. This kind of widespread scan was difficult t o explain exam ining one sit e. Before t he days of ht t p: / / www.incident s.org/ , St ephen Nort hcut t asked SANS m em bers t o look at t raffic at t heir individual sit es and see if t hey could provide any explanat ions about t he act ivit y. Hundreds of sit es report ed sim ilar act ivit y. A couple of sit es were able t o see t he HTTP request t hat was execut ed, and it appeared t o im plicat e a host ht t p: / / www.rusft psearch.net / . The sit e was available for a few days and it appeared t o be collect ing I Ps of any open proxy servers found. Ron Marcum of Vanderbilt Universit y discovered a PC on his net work t hat was scanning host s on ot her net works looking for port s 80, 8080, and 3128. He discovered a Troj an called RingZero t hat appeared t o be t he culprit . At a SANS conference in 1999, conference m em bers and inst ruct ors inst alled t he program t hat was discovered on t he Vanderbilt host and exam ined what it did. They were able t o recreat e t hat t his Troj an would scan ot her host s on web port s. The suspect ed infect ion m eans is via em ail or m p3 sharing. But , t his sem inal m alicious code is one of t he first t hat infect ed host s and gat hered som e valuable inform at ion from t he host s, and t hen used t he infect ed host s t o scan ot her host s. This is t he sam e m odel used for scans and at t acks t oday, albeit quit e a bit m ore sophist icat ed.

Su m m a r y Wit hout unnecessarily belaboring t he point , t he event s described in t his chapt er have dem onst rat ed t he added value of having TCPdum p or Shadow running at a sit e t o capt ure t he background t raffic. The first incident of a non- int rusion showed how TCPdum p can be invaluable because it s purpose is not exclusively t o show alert s of event s of int erest , but t o capt ure all t raffic. I t can provide an audit t rail of act ivit y t hat occurred, or m ore descript ively in t his case, of act ivit y t hat did not occur. I n addit ion, TCPdum p was used in t he scan incident t o assess t he react ion of host s

on t he m onit ored net work t o t he scan. Scans can be harm less dist ract ions when t here is no response by t he scanned host s, or in t his case, t hey can be a reason for concern. Alt hough m ost NI DS will inform you of scans, none will aut om at ically alert you of responding host s. I n t he t hird and final event s, TCPdum p was used t o get very specific inform at ion about t he fragm ent s or packet s in order t o m ake m ore accurat e evaluat ions of t he nat ure of t he at t ack. You can even begin t o do forensic invest igat ion about t he t ype of host s t hat are conduct ing t he host ile act ivit y. You will see a m ore t horough discussion of passive analysis of host ile t raffic in t he next chapt er.

Ch a pt e r 1 1 . M yst e r y Tr a ffic

Many t im es as a securit y analyst , you see som e kind of int erest ing t raffic and wish t hat you had t he t im e or resources t o invest igat e it or underst and it bet t er. You have a m uch bet t er chance of being able t o do t his if you are in a research posit ion rat her t han a busy operat ional environm ent where your exclusive purpose is t o m ake sure t hat no unaut horized access occurs. One such opport unit y t o do analysis of an event of int erest arose at a sit e where Shadow was used t o capt ure t raffic. The sit e was t he t arget of som e ext ensive unexplained act ivit y direct ed at TCP dest inat ion port 27374, which is oft en used by SubSeven. The explanat ion and findings of t he t raffic are discussed in t his chapt er. When we wit nessed t his act ivit y, we had a gut feeling t hat we were seeing som et hing unique j ust because of t he sheer volum e of it . We used Shadow's collect ed TCPdum p records t o analyze different fields and aspect s of t he packet t o com e t o our conclusions. This was a t eam effort conduct ed wit h t he help of co- workers Vern St ark and David Heinbuch. My suspicion is t hat m any people who gravit at e t o t he posit ion of securit y analyst enj oy working puzzles or m yst eries. The m yst ery of t his t raffic was unraveled sim ply using TCPdum p record capt ure, Perl program m ing t o exam ine and sum m arize different aspect s of t he t raffic, and Excel t o plot t he findings. Working on t his puzzle was not only a great learning experience of doing t raffic evaluat ion, and recovery aft er m aking errant assum pt ions, but it provided a lot of ent ert ainm ent t o som e t rue bit - heads.

Th e Eve n t in a N ut sh e ll Exam inat ion of an hour's t raffic on June 29, 2001 at 12: 00 capt ured by a Shadow sensor posit ioned out side a m onit ored sit e's perim et er firewall revealed a large

num ber of source host s scanning what appeared t o be t he sit e's Class B address space for TCP dest inat ion port 27374. Shadow ret rospect ively analyzes each hour's t raffic for anom alies. Anom alies, or m ore accurat ely, event s of int erest , are culled by running t he previous hour's collect ed TCPdum p t raffic t hrough a series of TCPdum p filt ers. One of t he filt ers looks for at t em pt ed TCP SYN connect ions from out side t he net work t o a host in t he net work. TCP dest inat ion port 27374 is associat ed wit h a Troj an known as SubSeven t hat can allow full access t o t he vict im 's m achine. We have seen plent y of large scans t o t he SubSeven port ; however, we had never seen a scan t hat generat ed such a large volum e of t raffic—nor had we seen one t hat had com e from m ult iple concurrent sources.

Cor r e la t ion of Sim ila r Act ivit y About t his sam e t im e, t he Syst em Adm inist rat ion, Net working, and Securit y ( SANS) I nt ernet St orm Cent er released a report on June 26, 2001 about a Microsoft Windows worm nam ed W32.leave.worm . The speculat ion was t hat t his worm was used t o m ake t he infect ed host a part icipant host , also known as a zom bie, in dist ribut ed denial of service ( DDoS) at t acks. According t o t he report , t he worm spread via connect ions t o host s list ening on TCP port 27374. The report not ed t hat t he worm scanned predet erm ined net work blocks associat ed wit h @Hom e and Eart hlink for dest inat ion port 27374. However, it m ade no m ent ion of synchronized scanning, nor did it m ent ion scanning of net works ot her t han t hose previously m ent ioned. Alt hough t he described worm act ivit y appeared t o be different t han t he act ivit y t hat was wit nessed at t he m onit ored sit e, it was possible t hat t he worm act ivit y had m ut at ed since t he init ial report .

Th e Tr a ffic The following out put represent s a handful of TCPdum p records t o provide t he general " flavor" of t he act ivit y. The source and dest inat ion host s are bold. These are t he first t en records associat ed wit h t he act ivit y on June 29; t here are four different source host s involved in scanning t en different dest inat ion host s. The t im est am ps associat ed wit h t he records should be regarded wit h caut ion. The sensor t hat capt ured t hese records is running Redhat Linux 7.1 wit h a packet capt uring m echanism known as t urbopacket com piled int o t he kernel. I t is supposed t o cont ain a m et hod for m ore efficient buffering, but it also appears t hat t he t im est am p precision has been lost . Tim est am ps should have m icrosecond fidelit y, but t hese t im est am ps appear t o have 10- m s resolut ion:

12:16:31.150575 ool-18bd69bb.dyn.optonline.net.4333 > 192.168.112.44.27374: S 542724472:542724472(0) win 16384 (DF) (ttl 117, id 13444) 12:16:31.160575 ool-18bd69bb.dyn.optonline.net.4334 > 192.168.112.45.27374: S 542768141:542768141(0) win 16384 (DF) (ttl 117, id 13445) 12:16:31.170575 24.3.50.252.1757 > 192.168.19.178.27374: S 681372183:681372183(0) win 16384 (DF) (ttl 117,id 54912) 12:16:31.170575 24-240-136-48.hsacorp.net.4939 >192.168.11.19.27374: S 3019773591:3019773591(0) win 16384 (DF) (ttl 117, id 39621) 12:16:31.170575 ool-18bd69bb.dyn.optonline.net.4335 > 192.168.112.46.27374: S 542804226:542804226(0) win 16384 (DF) (ttl 117, id 13446) 12:16:31.170575 cc18270-a.essx1.md.home.com.4658 > 192.168.5.88.27374: S 55455482:55455482(0) win 8192 (DF) (ttl 117, id 8953) 12:16:31.170575 24.3.50.252.1759 > 192.168.19.180.27374: S 681485650:681485650(0) win 16384 (DF) (ttl 117, id 54914) 12:16:31.170575 cc18270-a.essx1.md.home.com.4659 > 192.168.5.89.27374: S 55455483:55455483(0) win 8192 (DF) (ttl 117, id 9209) 12:16:31.170575 24.3.50.252.1760 > 192.168.19.181.27374: S 681550782:681550782(0) win 16384 (DF) (ttl 117, id 54915) 12:16:31.170575 cc18270-a.essx1.md.home.com.4660 > 192.168.5.90.27374: S 55455484:55455484(0) win 8192 (DF) (ttl 117, id 9465)

D D oS or Sca n At first , it was not apparent if t his was som e kind of at t em pt ed DDoS or an act ual coordinat ed scan of som e sort . During t he exam inat ion of t he act ivit y, we were fort unat e ( from t he analysis perspect ive) t o receive addit ional act ivit y on July 2, 2001 at 16: 00 t hat was rem arkably sim ilar. Aft er we received t he second scan, we began in earnest t o look at individual fields found in t he received packet s of bot h set s of act ivit y t o int erpret t he nat ure and int ent of t he act ivit y. Sour ce H ost s I n t he first scan, 132,706 t ot al packet s were received and t here were 314 unique source host s involved. Of t hose host s, only 17 ( approxim at ely 5.4 percent ) did not have DNS regist ered host nam es. I n t he second scan, 157,842 t ot al packet s were received. There were 295 unique source host s wit h only 24 ( approxim at ely 8.1 percent ) wit h unresolved host nam es. This alone is quit e t elling. Two choices for cat egorizing t he source host s are t hat t hey eit her do or do not reflect t he genuine source host t hat is sending t he t raffic. I f t he source host reflect s t he act ual sender, no subt erfuge is used in sending t he packet . I f t he source host is not t he act ual sender, a spoofed source I P num ber is placed in t he packet . Typically, when source I P num bers are spoofed, it is a random generat ion of

different I P num bers in t he inst ance of a flood. Ot her at t acks m ight use a select ion of one or m ore source I P num bers t hat m ight be eit her a decoy or an event ual t arget of som e kind. When t he source host reflect s t he t rue sender, t he int ent is m ore likely t han not t o be able t o receive a response t o t he sent t raffic. Therefore, it appears t hat t he act ivit y t hat was seen is using genuine source I P num bers. I f t his were a flood and t he source I Ps were spoofed using random ly generat ed I P num bers, it is st at ist ically unlikely t hat t hese I P num bers would resolve t o host nam es 91.9 t o 94.6 percent of t he t im e. I t would be unusual t hat I P num bers would be spoofed using a predet erm ined set of I P num bers t hat resolved t o host nam es, because t his t akes a lot of effort for lit t le or no gain. I t can be speculat ed t hat , because of t he sheer num ber of source host s involved, t hey m ost likely represent zom bie host s t hat have som ehow been exploit ed and owned. Many of t hese source net works are associat ed wit h cable m odem or DSL providers such as @Hom e and AOL. This corroborat es t he speculat ion of zom bie host s because hom e users are m ore likely t o be unaware of securit y t hreat s and less prot ect ed t han m ost com m ercial or larger net works wit h som e kind of perim et er prot ect ion. D e st in a t ion H ost s Next , t he analysis m oved t o exam inat ion of t he dest inat ion host s t o provide m ore evidence of a scan. The scanned net work is Class B wit h t he possibilit y of 65,535 I P num bers t o scan. The first scan t arget ed 32,367 unique dest inat ion host s and t he second scan t arget ed 36,638 unique dest inat ion host s. An init ial unsubst ant iat ed react ion t o m issed subnet s was t hat t here was som e prior reconnaissance perform ed t o direct ly t arget live host s. Aft er m ore t horough exam inat ion of t he dest inat ion host s, it was evident t hat m any of t he dest inat ion I P num bers t hat were scanned had no associat ed live host s. The m ore plausible explanat ion for t he m issing dest inat ion subnet s and dest inat ion host s is t hat perhaps t he zom bie or zom bies t hat were assigned t he m ission of scanning t hose subnet s were som ehow not act ive or responsive during t he scan and did not part icipat e. A single m issing dest inat ion host in an ot herwise scanned subnet m ight be int erpret ed as a dropped init ial packet rat her t han an om it t ed dest inat ion I P num ber. Alt hough one unique source host scanned m ost dest inat ion host s, m ult iple source host s scanned som e dest inat ion host s. The scanner appears t o have som e redundancy of scanned host s t o ensure a response. Sca n n in g Ra t e s Anot her indicat ion of a scan versus a flood was t he scanning rat e of t he source host s. Bot h scans sust ained som e kind of act ivit y for five or six m inut es; however, t he ram p- up t im e was fast , and t here was a burst of act ivit y for t he first t wo

m inut es. The m easure of bandwidt h consum pt ion was as follows. Each packet was a SYN packet wit h TCP opt ions and no payload. Most packet s had a lengt h of 48 byt es, a few had m ore, and a few had 4 byt es less, depending on t he num ber and t ypes of TCP opt ions used. Packet s had a st andard 20- byt e I P header wit h no I P opt ions. Because t he m aj orit y of packet s had a lengt h of 48 byt es, t his was used as t he packet lengt h for t he com put at ion of bandwidt h consum pt ion. Because t hroughput or bandwidt h is m easured in bit s per second, t he packet lengt h was 384 ( 48 * 8) bit s. The scan on June 29 reached a m axim um rat e of 1.7Mbps at peak. The second scan on July 2 reached a m axim um rat e of 2.4Mbps at peak. This did not adversely affect t he m onit ored sit e, but a sit e wit h a sm aller ingress pipe such as a T- 1 wit h 1.554Mbps capacit y m ight have suffered a t em porary denial of service as a side effect of t he scan. Figure 11.1 shows t he bit s per second during peak scan m inut es. Figu r e 1 1 .1 . Bit s pe r se con d.

Looking at t he plot s in Figure 11.1 t oget her, it is apparent from t he general cont ours t hat t he scanning rat es for bot h scans were very sim ilar. I n fact , bot h scans reached peak scanning rat es at exact ly 21 seconds aft er t he scan began. As discovered lat er, aft er exam ining t he t raffic using different represent at ions, t his peak act ivit y indicat ed som e kind of coordinat ion by t he " com m ander" who allocat ed scanning assignm ent s and rat es for t he zom bies. Peak rat es could have occurred because t here were m ore scanning host s during

t hat second or because t he num ber of packet s sent by host s increased. Furt her scrut iny of t he dat a revealed t hat t he peaks and valleys correlat ed wit h an increased num ber of scanning host s. The 21- second peak rat e t hat was observed yet again on a t hird scan on Novem ber 1 was indeed a m yst ery. However, it was observed t hat t he scanning host s sent ret ries of init ial SYN connect ions t hat received no response. This is t ypical TCP behavior, and m any TCP/ I P st acks will at t em pt 3 ret ries aft er t he init ial SYN, wit h a form ula of wait ing 3 seconds before t he first ret ry, doubling t he wait t im e t o 6 seconds for t he second ret ry and doubling t he wait t im e yet again t o 12 seconds for t he t hird and final ret ry. Hence, t he aggregat e t im e t hat passes bet ween t he init ial SYN and t he final ret ry is 21 seconds. And so, when init ial SYN at t em pt s only were plot t ed by t im e as in Figure 11.2, t he 21- second peak disappears. Figu r e 1 1 .2 . Ju n e 2 9 , 2 0 0 1 in it ia l SYN a t t e m pt s.

This only part ially explains t he 21- second peak. I f t his peak were due st rict ly t o ret ries alone of t he sam e host s, sim ilar peak act ivit y should be observed at 3 and 9 seconds as well. Figure 11.3 shows t wo separat e t ypes of connect ion at t em pt s by t im e for t he June 29 scan—t he solid line shows init ial SYN at t em pt s and t he dashed line shows ret ries of t hose init ial SYN at t em pt s. This m ore com plet ely explains t he 21- second peak. Figu r e 1 1 .3 . Ju n e 2 9 , 2 0 0 1 in it ia l SYN s a n d r e t r ie s.

Peak act ivit y occurs at 12: 16: 52. As expect ed, t his corresponds t o t he 3 rd ret ry of t he spat e of at t em pt ed SYN connect ions sent at 12: 16: 31. Furt herm ore, it corresponds t o t he second ret ry of t he deluge of anot her set of init ial SYN at t em pt s sent 9 seconds before peak act ivit y at 12: 16: 42. More so, in bot h scans, it appears, at least at first , t hat t he wave of init ial SYN connect ions com es in 12second int ervals. The overlap of ret ries from t his part icular t im ing pat t ern is why t he 21- second peak act ivit y was wit nessed.

Th e 2 1 - Se con d M yst e r y One of t he m ost int riguing revelat ions of t he exam inat ion of t his SubSeven t raffic was t he 21- second t im e preceding t he peak act ivit y for t he init ial t wo scans, and lat er a t hird, t hat were observed. I t was clear t hat t here was som e m eaning and explanat ion associat ed wit h t his; t his couldn't be a m ere coincidence because it occurred t hree t im es. I have an annoying habit : When I 'm st um ped and frust rat ed by m y inabilit y t o figure som et hing out , I st art plaguing colleagues. Most have learned t o dism iss m e wit h som e plausible excuse like, " There are free donut s in t he cafet eria. See you lat er." But , I cornered m y co- worker and longt im e bicycling buddy, Vern, and asked him t o ponder t his m yst ery. Wit hin seconds, and st ill a good chance t o get t hose cafet eria donut s, he said, " Oh, t hat 's easy; it 's t he com bined backoff t im es for ret ries." This insight m ade us ret hink our approach, and we event ually plot t ed t he t raffic separat ely for init ial SYNs and ret ries, allowing us t o discover t hat t he 21- second peak rat e was an overlap of ret ries from different init ial waves of SYN act ivit y.

Fin ge r pr in t in g Pa r t icipa n t H ost s The assum pt ion now is t hat t he zom bie host s have been " infect ed" wit h som e m alware t hat is generat ing t he scanning act ivit y. The quest ion t hen becom es t his: I s t here a specific operat ing syst em t hat has been exploit ed, t ransform ing t he host int o a zom bie for t his scan? An exam inat ion of passive fingerprint s can assist in

ident ificat ion of zom bies' operat ing syst em s. This assum es t hat t he packet s com ing from t hese host s are not craft ed t o change default values, such as TCP window size, init ial TTL, and TCP opt ions. Passive fingerprint ing cat egorizes operat ing syst em s by looking at unique field values in t he packet s t hat have been sent . As we have discussed, different operat ing syst em TCP/ I P st acks choose unique values for cert ain fields, such as Tim e t o Live ( TTL) , TCP window size, and TCP opt ions. There are also ot her fields t hat can be exam ined, such as t he Type of Service ( TOS) value and t he don't fragm ent ( DF) flag. But , because m ost operat ing syst em s use a default TOS value of 0 and set t he DF flag, t his m ight only det erm ine t he sm all percent age of unusual values sent from ot her operat ing syst em s. And, t hese t wo fields are best exam ined in conj unct ion wit h ot her fields and not alone. Table 11.1, provided by t he Honeynet Proj ect , was used in det erm ining som e of t he scanning host s' operat ing syst em s. The lines t hat are highlight ed represent t he operat ing syst em and associat ed fingerprint s of t he m aj orit y of t he scanning host s t hat were observed for t his act ivit y.

Ta ble 1 1 .1 . Pa ssive Fin ge r pr in t in g Va lu e s by Ope r a t in g Syst e m

# OS

VERSI ON

PLATFORM

TTL

W I N D OW

DF

TOS

# ---

-------

--------

---

-----------

--

---

DC- OSx

1.1- 95

Pyram id/ NI LE

30

8192

n

0

Windows

9x/ NT

I nt el

32

5000- 9000

y

0

Net App

OnTap

5.1.2- 5.2.2

54

8760

y

0

HPJet Direct

HP_Print er

59

2100- 2150

n

0

AI X

4.3.x

I BM/ RS6000

60

16000- 16100

y

0

Cisco

11.2

7507

60

65535

y

0

Digit alUnix

4.0

Alpha

60

33580

y

16

I RI X

6.x

SGI

60

61320

y

16

OS390

2.6

I BM/ S390

60

32756

n

0

Reliant

5.43

Pyram id/ RM1000

60

65534

n

0

FreeBSD

3.x

I nt el

64

17520

y

16

Jet Direct

G.07.x

J3113A

64

5804- 5840

n

0

Linux

2.2.x

I nt el

64

32120

y

0

OpenBSD

2.x

I nt el

64

17520

n

16

OS/ 400

R4.4

AS/ 400

64

8192

y

0

SCO

R5

Com paq

64

24820

n

0

Solaris

8

I nt el/ Sparc

64

24820

y

0

FTX( UNI X)

3.3

STRATUS

64

32768

n

0

Unisys

x

Mainfram e

64

32768

n

0

Net Ware

4.11

I nt el

128

32000- 32768

y

0

Windows

9x/ NT

I nt el

128

5000- 9000

y

0

Windows

2000

I nt el

128

17000- 18000

y

0

Cisco

12.0

2514

255

3800- 5000

n

192

Solaris

2.x

I nt el/ Sparc

255

8760

y

0

This t able of inform at ion was obt ained at ht t p: / / proj ect .honeynet .org/ papers/ finger/ t races.t xt . Ar r ivin g TTL Va lu e s I f you recall, t he arriving TTL values can be used t o help ident ify t he scanning host 's operat ing syst em . Different operat ing syst em s use different init ial TTL values when sending a packet . Each rout er t hrough which t he packet t ravels on it s j ourney from source t o dest inat ion host exam ines t he TTL value and decrem ent s it by 1. This becom es an indicat ion of t he num ber of " hops" t hat t he packet has t raveled. I f a rout er ever discovers a TTL of 0, it discards t he packet and sends back an I CMP error m essage of " t im e exceeded in- t ransit " t o t he sending host . This inform s t he sending host t hat t he packet has exceeded it s welcom e on t he I nt ernet . This is a m echanism t hat is used t o discard lost packet s, such as ones t hat have becom e caught in a rout ing loop. I nit ial TTLs of m any operat ing syst em s have t ypical values of 32, 64, 128, and 255. These m ight be different per prot ocol—TCP, UDP, or I CMP. For inst ance, Windows NT 4.0 Service Pack 6 has an init ial TTL value of 128 for TCP and an init ial TTL value of 32 for I CMP packet s sent . Fort unat ely, t his exam inat ion is lim it ed t o TCP so t here is no need t o account for prot ocol differences. The arriving TTL values are exam ined and are helpful in est im at ing t he init ial TTL values. The caveat here is t hat alt hough m ost operat ing syst em s will be configured t o use t he default init ial TTL values, t hese can be changed. All t hat can be det erm ined wit h absolut e cert aint y from t he arriving TTL is t hat it is less t han t he init ial TTL. Of course, t his assum es t hat t he source host and dest inat ion host are not direct ly connect ed t o t he sam e local net work, in which case t he packet could pass from source t o dest inat ion wit hout t he TTL being decrem ent ed. Exam inat ion of Figure 11.4 for June 29, 2001 shows t hat t here are t hree clust ers

of arriving TTL values for t he scans. More specifically, t he closest scanning host appears t o be 8 hops away, and t he m ost dist ant appears t o be 25 hops away from t he capt uring sensor int erface. The assum pt ion is t hat t he scanning host s had init ial TTL values of 128, 64, and 32, and t he arriving TTL values are associat ed wit h an init ial TTL value t hat is great er t han t he init ial TTL value by t he least am ount . For inst ance, if an arriving TTL is 50, it is assum ed t o have an init ial TTL value of 64 and not 128, alt hough eit her init ial TTL value would be valid. Figu r e 1 1 .4 . Ju n e 2 9 , 2 0 0 1 a r r iving TTL va lu e s.

I n t he June 29 scan, t he largest percent age of scanning host s, 92.13, had an est im at ed init ial TTL of 128. More t han 37 percent of t he host s wit h an init ial TTL of 128 were approxim at ely 11 t o 13 hops away from t he sensor. According t o Table 11.1, an init ial TTL value of 128 is indicat ive of Windows 9x/ NT/ 2000. An init ial TTL value of 32 is Windows 9.x/ NT, which com prised 2.66 percent of t he scanning host s. The init ial TTL value of 64 is associat ed wit h m any of t he UNI X plat form s, including t he Linux 2.2.x kernel. The percent age of host s wit h an init ial TTL of 64 was 5.2. Exam inat ion of Figure 11.5 for July 2, 2001 shows t he sam e clust ering. More specifically, t he closest scanning host appeared t o be 8 hops away, and t he m ost dist ant appeared t o be 27 hops away from t he capt uring sensor int erface. Figu r e 1 1 .5 . Ju ly 2 , 2 0 0 1 a r r ivin g TTL va lu e s.

Looking at t he July 2 scan, t he largest percent age of scanning host s, 92.29, had an init ial TTL of 128. More t han 37 percent of t he host s wit h an init ial TTL of 128

were approxim at ely 11 t o 13 hops away from t he sensor. 2.36 percent of t he scanning host s had an init ial TTL of 32. Finally, 5.35 percent of t he scanning host s had an init ial TTL of 64. The det erm inat ion from t his is t hat t he scanning host s are not exclusively Windows host s, but it appears t hat Windows host s are t he m aj orit y of t he scanners. This m eans t hat what ever m alware is exploit ing t he scanning host s, it is not exclusive t o Windows. Alt hough t he x- axis scaling for plot s in Figures 11.4 and 11.5 doesn't readily show t his, t here was a very dist inct clust ering around t he est im at ed init ial TTL values. For inst ance, in t he June 29 scan, t here is a not iceable gap or absence of packet s wit h arriving TTL values bet ween 22 and 42 and bet ween 56 and 103. Sim ilar behavior is observed for t he July 2 scan. TCP W in dow Size A host advert ises t he TCP window size when it at t em pt s t o m ake an init ial connect ion. The window size is a dynam ic value t hat changes as inform at ion is exchanged bet ween host s and represent s t he current TCP buffer size for t he incom ing dat a. This buffer allows m ult iple packet s t o be sent and queued before passing t hem t o TCP and t he applicat ion. More sim ply, a given operat ing syst em has a default value for t he TCP window size, and t he window size can change dynam ically as dat a is received and processed. But , t he init ial window size can be used t o fingerprint t he operat ing syst em . The user or adm inist rat or can cust om ize t his, but com m only t he default is used. As you can see in Figure 11.6, t he bulk of t he connect ions had an init ial window size of 8192. This is associat ed wit h Windows 9x/ NT connect ions according t o Table 11.1. Alt hough t he t able doesn't have a window- size ent ry for 16384, research has discovered it is associat ed wit h Windows 2000. Table 11.1 alludes t hat a window size of 65535 is associat ed wit h Cisco. However, it appears t hat t he high percent ages associat ed wit h t his window size would include ot her operat ing syst em s. Figu r e 1 1 .6 . Sca n n in g h ost TCP w indow size .

Search engines on t he I nt ernet failed t o find any operat ing syst em associat ions wit h a window size of 65535. At t em pt s were m ade t o exam ine a week's collect ion of TCPdum p dat a for t he m onit ored sit e t o find host s t hat had a window size of 65535. Only a dozen of approxim at ely 5,500 host s were found wit h a window size of 65535. A scan by nm ap could not det erm ine t he operat ing syst em s. Som e of t he host s had port s open, such as 135 and 139, which would indicat e Windows versions prior t o Windows 2000. Ot hers had port 445 list ening, which was int roduced in Windows 2000 t o support Server Message Block ( SMB) t alking direct ly over TCP/ I P wit hout t he need for t he int erm ediat e layer of Net BI OS over TCP/ I P ( NBT) . Yet , ot her host s wit h a window size of 65535 list ened at port s 111 ( port m apper) , 515 ( line print er daem on) , and 6000 ( X11) , which are all associat ed wit h UNI X host s. No conclusions could be reached about t he operat ing syst em associat ed wit h a window size of 65,535 based on t hese findings. Ot her unique window sizes t hat were seen were 32120, associat ed wit h Linux, which was found in t he June 29 scan only and com prised .19 percent of t he t ot al scanning host s. A window size of 8760 was seen in bot h scans and reflect s a Solaris host . The first scan had 5.21 percent host s wit h t his window size, and t he second scan had 6.60 percent host s wit h t his window size. The conclusion t hat can be drawn exam ining t he TCP window size is t he sam e as exam ining t he arriving TTL values. Looking at Figure 11.6, m ost of t he scanning host s appear t o have a window size associat ed wit h Windows, yet it also appears t hat operat ing syst em s ot her t han Windows are involved in t he scanning t oo. TCP Opt ion s

Anot her int erest ing field for exam inat ion is t he Maxim um Segm ent Size ( MSS) , which is found in t he TCP opt ions. This represent s t he m axim um am ount of payload t hat a TCP segm ent can carry. This does not include t he TCP header and t he I P header. Generally speaking, t he MSS is 40 byt es less t han t he Maxim um Transm ission Unit ( MTU) , assum ing a 20- byt e I P header wit h no I P opt ions and a 20- byt e TCP header wit h no TCP opt ions. The MTU can t hen be used t o det erm ine t he m edia on which t he sending host resides. I n som e inst ances, alt hough not t his one, t he MTU, and hence t he MSS, m ight reflect t he pat h MTU. The sender m ight send a " discovery" packet t hat looks for t he sm allest MTU from source t o dest inat ion by set t ing t he DF flag on t he packet . I f no I CMP error m essages are ret urned, it is assum ed t hat using t he size of t he local MTU for packaging packet s will not cause fragm ent at ion. I f an I CMP error m essage " unreachable – need t o frag ( m t u # # # ) " is ret urned, it cont ains t he MTU size ( ###) of t he link t hat is sm aller t han t he size of t he local MTU. The sender can decrease t he size of t he packet s t o avoid fragm ent at ion. The point is t hat it is possible t hat t he MSS m ight not reflect t he local MTU. However, because t here is no indicat ion of discovery packet s or t hat pat h MTU was used, t he assum pt ion is t hat t he MSS does reflect t he local MTU. Figure 11.7 reveals t hat t he great est percent age of scanning host s resided on a link wit h an MTU of 1500. This is indicat ive of Et hernet , found in LAN connect ions or DSL. The MTU of 576 is associat ed wit h PPP or I SDN. Finally, t he MTU of 1454 is associat ed wit h PPP over Et hernet t hat is also found on DSL connect ions. Figu r e 1 1 .7 . M SS/ M TU v a lu e s.

Alt hough t he MSS of 536 is associat ed wit h PPP and dial- up m odem s, it is supposed t hat m ost of t he host s reside on I SDN, which uses t he sam e MSS. The scenario is t hat t hese are all zom bie host s t hat are direct ed t o do som e t ype of act ivit y at a given t im e. Eit her t hey respond t o a cat alyst or t hey all have som e kind of t im e synchronizat ion and are direct ed t o respond at a given t im e. The idea of part icipant s from dial- up m odem s is wort h som e reflect ion. First , if a zom bie is associat ed wit h a dial- up connect ion, t his m ight not be a sust ained connect ion unless t here is som e kind of dedicat ed phone line for t he t raffic. Addit ionally, m any dial- up connect ions are at t he m ercy of Dynam ic Host Configurat ion Prot ocol ( DHCP) wit h a leased I P num ber for a cert ain period of t im e. How would t he " com m ander" direct a zom bie wit h a changing I P num ber t o launch t he act ivit y? One guess is t hat t he zom bies report hom e t o t he com m ander periodically. Therefore, only ones t hat are act ive and online j ust before t he at t ack are direct ed t o part icipat e in t he at t ack. Anot her quest ion arises from t his discussion. I t has already been det erm ined t hat zom bies have assignm ent s of m ost ly unique address ranges t o scan. I s t here som e kind of form ula used t o assign t he address ranges t o scan so t hat t he m axim um num bers of host s get scanned? The suspicion is t hat m ost of t he part icipat ing zom bies have a sust ained and dedicat ed I nt ernet connect ion, but t his doesn't adequat ely explain t he m issing dest inat ion host s and subnet s. TCP Re t r ie s As m ent ioned, when a source host at t em pt s a TCP connect ion t o a dest inat ion host and is unsuccessful, yet get s no indicat ion of t he failure, it at t em pt s one or m ore ret ries. A source host is not not ified of a failure if t he connect ion packet never get s t o t he dest inat ion or t he dest inat ion host 's response doesn't get back t o t he source. I n t he case of our scanned net work, t he act ivit y t o port 27374 was blocked.Yet , t he firewall t hat blocks t he act ivit y " silent ly" drops t he packet wit h no not ificat ion in t he form of an I CMP error m essage t o t he original source host t hat t here is a problem . The purpose of t he silent drop is so t hat no addit ional reconnaissance is dissem inat ed about our net work perim et er and defense. For t he purposes of t his invest igat ion, a TCP ret ry is defined as one t hat has t he sam e source and dest inat ion host s, port s, and TCP sequence num bers as t he init ial at t em pt . The num ber of successive ret ries and t he backoff t im e bet ween ret ries is TCP/ I P st ack dependent . Ret ries are associat ed wit h source code t hat uses socket connect ions. I n ot her words, t he source code is writ t en so t hat t he socket calls go t hrough t he proper layers of t he TCP/ I P st ack. I n t his case, t he socket uses t he TCP and I P layers t o form t he appropriat e headers and values for t hose headers.

The alt ernat ive is known as a raw socket , which does not use t he TCP/ I P st ack t o form t he packet . I nst ead, t he program m er is responsible for supplying t he appropriat e headers and dat a. This packet is writ t en direct ly t o t he net work int erface card. Many scanners such as nm ap and hping2 use raw socket s. This scan m anifest ed m ult iple ret ries when t he dest inat ion host was unresponsive. What does t his m ean? That regular and not raw socket s were used? First , t he scanning host really want ed t o m axim ize t he opport unit y t o elicit a response from t he dest inat ion host —m ore indicat ive of scan behavior t han flood behavior. Flood behavior would likely send packet s using raw socket s as fast as possible. Second, raw socket s require an addit ional level of com plexit y because t hey require t he inst allat ion of an applicat ion program m ing int erface for packet capt ure on t he scanning host —eit her winpcap for Windows or libpcap for UNI X. The use of st andard socket s sim plifies t he set up required t o scan.

Su m m a r y The det erm inat ion is t hat t his was a very efficient scan looking for host s list ening on TCP port 27374. The scan was conduct ed by zom bie host s, which were m ost ly Windows host s. I t appears t hat host s wit h ot her operat ing syst em s were involved, yet t hey played only a sm all part in t he percent age of scanning host s. The significance of t his is t hat t he m eans of infect ion of t he zom bie host s does not appear t o be Windows- specific. I t is unknown whet her t he percent age of Windowsbased scanning host s and t he percent age of scanning host s t hat have ot her operat ing syst em s act ually m irror t he percent age of Windows versus all ot her operat ing syst em s t hat are found on t he I nt ernet . The im plicat ion here would be t hat t he operat ing syst em s of t he zom bie host s m ight be consist ent wit h a norm al dist ribut ion found on t he I nt ernet . Anot her im plicat ion is t hat t he percent age of zom bie host s having a part icular operat ing syst em m ight represent t he ease of com prom ise for t hat operat ing syst em . I s t he sole purpose of t his scan t o efficient ly ident ify host s list ening on port 27374? I t can be surm ised t hat not all of t he zom bie host s were exploit ed by t he SubSeven Troj an. SubSeven is a Windows- based Troj an, and it appeared t hat not all t he zom bie host s were Windows. Perhaps t here are SubSeven Troj ans t hat have been developed for ot her operat ing syst em s as well. What ever t he exploit used t o " own" t he zom bies, t he " com m ander" knew about t he owned zom bie host s and had no need t o scan t o find t hem . I s it possible t hat t his scan search was t o find ot her candidat e zom bies owned by anot her com m ander? This assum es t hat t hese new zom bie host s would be Windows- based because t hey would be list ening at t he SubSeven port . The new zom bies m ay be used for act ivit y ot her t han t he scanning t hat was wit nessed at our sit e. What ever t he purpose of t his scan, it looks like a pret t y sophist icat ed way t o m axim ize a scan. I n a couple of m inut es, over 30,000 dest inat ion host s were scanned. This act ivit y dem onst rat es t he evolving sophist icat ion in zom bie act ivit y

and m alicious code in general, as we have wit nessed wit h Code Red and nim da worm s. I t also shows t he burgeoning num ber of exploit ed host s t hat can be m arshaled int o act ive dut y because of t he innocence or disbelief of hom e users, paired wit h always- on connect ivit y, and operat ing syst em s and applicat ions t hat com e ready- assem bled for loot ing and pillaging.

Pa r t I I I : Filt e r s/ Ru le s for N e t w or k M on it or in g 12 Writ ing TCPdum p Filt ers 13 I nt roduct ion t o Snort and Snort Rules 14 Snort Rules—Part I I

Ch a pt e r 1 2 . W r it in g TCPdu m p Filt e r s

This is t he first of t hree chapt ers t hat discusses writ ing filt ers or signat ures t o det ect anom alous behavior. The aut hors have chosen t o discuss t hese part icular filt ers and signat ures for a couple of reasons. The first is because t hese signat ures are available wit h freeware and available t o t he m asses—even t he im poverished. The second reason is t hat t here are so m any I DS packages t oday, it is alm ost im possible t o cover t hem and yet not be accused of bias or favorit ism because of om issions. As a fair com prom ise, we have chosen t his chapt er t o discuss TCPdum p and t he following t wo chapt ers t o discuss Snort signat ures. This chapt er discusses how t o select records from TCPdum p using filt ers t o det ail t he specifics of records of int erest . The following chapt er will int roduce t he reader t o Snort ( a free NI DS) and Snort signat ures. The final of t he t hree chapt ers will provide addit ional inform at ion on com posing Snort signat ures. The t im e- honored TCPdum p program com es wit h an ext ensive filt er language t hat you can use t o look at any field, com binat ion of fields, or bit s found in an I P dat agram . I f you like puzzles and don't m ind a bit of t inkering, you can use TCPdum p filt ers t o ext ract different anom alous t raffic. Mind you, t his is not t he t ool for t he feint of heart or for t hose of you who are shy of get t ing your brain a bit frazzled. Those who prefer a packaged solut ion m ight be bet t er off using t he com m ercial product s and t heir GUI s or filt ers. This chapt er int roduces t he concept of using TCPdum p and TCPdum p filt ers t o det ect event s of int erest . TCPdum p and TCPdum p filt ers are t he backbone of a freeware I DS Shadow, and so t he recom m ended suggest ion is t o download t he current version of Shadow at www.nswc.navy.m il/ I SSEC/ CI D t o exam ine and enhance it s nat ive filt ers. This t akes care of aut om at ing t he collect ion and processing of t raffic, freeing you t o concent rat e on cust om izing t he TCPdum p filt ers for bet t er det ect s.

Specifically, t his chapt er discusses t he m echanics of creat ing TCPdum p filt ers. You learn different t echniques for excavat ing byt es and bit s wit hin t he I P dat agram using t hese filt ers. Different TCPdum p filt ers are developed t o show you how t o ext ract event s of int erest . This chapt er t ries t o build on t hese foundat ions and leads up t o developing m ore com plex and advanced filt ers.

Th e M e ch a n ics of W r it in g TCPdu m p Filt e r s By default , TCPdum p exam ines or collect s all of t he records read from eit her t he net work or from a file. But oft en you will want t o exam ine or collect only records wit h specific values set in ident ified fields in t he I P dat agram t o look for signs of m alicious act ivit y direct ed at your net work. TCPdum p filt ers can be used t o specify an it em of int erest , such as a field in t he I P dat agram for record select ion. Such it em s m ight be part of t he I P header ( t he I P header lengt h, for exam ple) , t he TCP header ( TCP flags, for exam ple) , t he UDP header ( t he dest inat ion port , for exam ple) , or t he I CMP m essage ( m essage t ype, for exam ple) . TCPdum p provides som e m acros for com m only used fields, such as " port " t o indicat e a source or dest inat ion port , or " host " t o indicat e an I P num ber or nam e of a source or dest inat ion host . We won't use t hese in t he exam ples—not for t he sake of proud academ ics, but because t he fields we are int erest ed in do not have m acros, and so we m ust use t he form at of referencing a field by t he prot ocol and displacem ent in t erm s of byt es int o t hat prot ocol. TCPdum p assigns a designat ed nam e for each t ype of header associat ed wit h a prot ocol. Much as you would expect , " ip" is used t o denot e a field in t he I P header or dat a port ion of t he I P dat agram , " t cp" for a field in t he TCP header or dat a of t he TCP segm ent , " udp" for a field in t he UDP header or dat a of t he UDP dat agram , and " icm p" for a field in t he I CMP header or dat a of t he I CMP m essage. Now, we have t o reference a field in a given prot ocol by it s displacem ent in byt es from t he beginning of t he prot ocol header. For inst ance, ip[ 0] indicat es t he 0 byt e offset of t he I P dat agram , which happens t o be part of t he I P header ( rem em ber, count ing st art s at 0) . t cp[ 13] is byt e 13 offset int o t he TCP segm ent , which is also part of t he TCP header, and icm p[ 0] is t he 0 byt e of t he I CMP m essage, which is t he I CMP m essage t ype. For t his discussion, we use t he following form at t o creat e a TCPdum p filt er:

[offset:length]

All t he init ial filt ers t his chapt er covers reference Figure 12.1, which is t he st andard layout of t he I P header. Not ice t hat each of t he rows has 32 bit s, ranging in value from 0 t hrough 31. Essent ially, each row is com posed of 4 byt es—and don't forget t hat count ing st art s wit h 0. That is one of t he hardest t hings t o

com m it t o m em ory. Figu r e 1 2 .1 . Th e I P he a de r .

Suppose t hat you want t o use TCPdum p t o select any dat agram t hat has an em bedded prot ocol of I CMP. Refer t o Figure 12.1 and not ice t his part icular prot ocol field is locat ed 9 byt es offset ( last rem inder: st art count ing at 0) int o t he I P header. Therefore, we denot e t his field as ip[ 9] . Not ice also t hat t he TCPdum p filt er form at called for an offset : lengt h; t he im plied lengt h is 1 byt e, and t he lengt h is t ypically used if you want t o span m ore t han a single byt e. Now t hat you have locat ed t he 1- byt e field t hat st ores t he em bedded prot ocol, you need t o know t hat a value of 1 in t his field represent s I CMP. To com pose t he ent ire filt er t o find I CMP records, use t he filt er ip[ 9] = 1. I f t his were used t o collect records off t he net work, you would run TCPdum p as follows:

tcpdump 'ip[9] = 1'

This reads from t he default net work int erface and collect s only I CMP records. You em bed t he filt er in single quot at ion m arks t o keep t he UNI X shell from t rying t o int erpret t he filt er. Anot her TCPdum p opt ion used for m ore com plicat ed filt ers is t he –F opt ion of TCPdum p, which point s TCPdum p t o a file where t he filt er is locat ed. You could creat e a file, / t m p/ filt er, cont aining t he t ext " ip[ 9] = 1" which could t hen be used in t he following com m and:

tcpdump –F /tmp/filter

This would have yielded t he sam e result s as t he TCPdum p com m and t hat included t he filt er in t he com m and line it self. This opt ion is usually used for long filt ers or aut om at ed TCPdum p processes t o avoid com m and- line ent ry of t he filt er.

Bit M a sk in g We need t o int roduce a couple m ore concept s while we're at it . The TCPdum p filt er language is not a robust language com pared t o t he const ruct s and operat ions available in ot her languages such as C or Perl, for inst ance. Oft en, we have t o go back t o t he ancient root s of assem bler language—like m anipulat ions t o ext ract fields t hat don't fall on byt e boundaries. TCPdum p is fairly st raight forward and coherent when you are dealing wit h a field t hat falls on a byt e boundary and you are looking at all 8 bit s. Alt hough you have discovered how t o span byt es by specifying t he lengt h aft er t he offset , what happens if you want t o look at only cert ain bit s or a range of bit s in a byt e? I n ot her words, you don't want t o look at t he ent ire byt e. This is where t hings get a lit t le hairy, and t his discussion assum es t hat you have m ast ered t he rudim ent s of binary and hexadecim al. Pr e se r vin g a n d D isca r din g I n dividu a l Bit s Take a look at t he st ruct ure of t he I P header again. Now look at t he first byt e in t he I P header and not ice t hat it is act ually t wo 4- bit fields. Each of t hese 4- bit fields is known as a nibble. What if you want ed t o exam ine t he 4- bit header lengt h only, and didn't care about t he value in t he 4- bit version field? You really j ust want t o look at t he low- order nibble. How do you discard t he high- order nibble so t hat you can concent rat e on t he value of t he 4- bit I P header lengt h alone? I n essence, you want t o t urn t he high- order 4 bit s int o 0s. Doing so enables you t o reference t he first byt e and look at t he low- order nibble alone. I f t he quest ion " how t he heck do I do t hat ?" is rolling around t he t ip of your t ongue, you are following t his discussion in hot pursuit . Rem em ber back t o Boolean arit hm et ic? A well- deserved groan or t wo is m erit ed or even expect ed. Personally, I don't rem em ber anyone who enj oyed a good t rut h t able, but unfort unat ely, you have t o delve back int o t he far recesses of your brain t o resurrect t he Boolean AND operat or. Does Table 12.1 bring back any night m ares?

Ta ble 1 2 .1 . AN D Tr u t h Ta ble

BI T A

AN D

BI T B

RESULT

0

0

0

1

0

0

0

1

0

1

1

1

This t able shows all t he possible binary bit values and t he result s of ANDing t he bit s. The only t im e t hat 2 bit s have a result ing value of 1 is when bot h ANDed bit s are 1. What does t his m ean t o t his discussion of TCPdum p filt ers? You m ight have forgot t en t he original challenge: You need t o zero out t he high- order nibble of t he first byt e in t he I P header so t hat you can focus on t he low- order nibble. Well, what if you can AND t he value found in t he first byt e of t he I P header wit h all 0s in t he high- order nibble, which has t he effect of discarding t hem ? Then, you can preserve t he original value in t he low- order nibble by ANDing all t hose bit s wit h 1s. Consider how t his is done. Take a look at Figure 12.2. I n t he rect angles, you see t he first byt e of an act ual I P header divided int o t wo 4- bit chunks. Exam ine t he value in t he dat agram ; t he high- order nibble has a value of 0100 wit h a 1 in t he 2 2 posit ion, which yields 4. This is t he version of I P—I P version 4, in t his case. Now look at t he low - order nibble. I t has a value of a 1 in t he 2 2 posit ion and a 1 in t he 2 0 posit ion, so we have a 4 + 1 ( or 5) . This is t he I P header lengt h.Very unfort unat ely, t he m et ric for t his is not byt es as you m ight expect . I t would be a lot easier t hat way, but t o save on space required t o st ore t his value, t his represent s not a byt e, but a word. A word is 32 bit s, or 4 byt es. To convert a value t hat you find in t his lengt h field t o byt es, you m ust m ult iply by 4. This m eans t hat t his is a 20- byt e header lengt h, which is t ypical for a header t hat has no opt ions. Figu r e 1 2 .2 . Bit m a sk in g.

Cr e a t in g t h e M a sk Let 's get on wit h t he t ask of discarding t he four high- order bit s. Look at Figure 12.2 again, but t his t im e at t he line under t he act ual value found in t he first byt e of t he I P dat agram . This is what we have designat ed t he " m ask," or t he byt e t hat will be ANDed wit h t he original value, bit by bit t o discard t he high- order bit s and preserve t he low - order bit s. I f you were t o st art t he process at t he high- order ( left m ost ) bit , you would find a 0 in t he value bit and a 0 in t he m ask bit . On t he

line below it , you see t he result ing bit is 0. Logically, we have a 0 in t he value bit t hat we AND wit h a 0 in t he m ask bit and t he result is a 0. Rem em ber, if we AND any value bit wit h a 0, t he result is a 0. Using t his line of t hought , our ot her m ask bit s for t he high- order nibble are also 0s. As you see, t he result ing value for t he high- order nibble is 0000, which is exact ly what we want ed—t o zero- out t his field t o focus on t he lower- order nibble. Because we are dealing wit h an ent ire byt e, we also need t o m ask t he low - order nibble—we cannot ignore t hat . St aring wit h t he left m ost bit of t he low- order nibble, we find a 0 in t he value bit and a 1 in t he m ask bit . These t wo values ANDed yield a 0, t hereby preserving t he original value bit . Next , we see t hat a 1 in a value bit ANDed wit h a 1 in t he m ask bit also preserves t he value bit . You can see t he pat t ern; all 1s in t he m ask for t he low- order nibble preserves t he loworder nibble. And, looking at t he result ing value, we see t hat we have accom plished what we set out t o do—t o look exclusively at t he value of t he I P header lengt h. Yes, we have t o go t hrough all of t his because we cannot look at j ust part of a byt e! Whew! We need t o cover j ust one m ore st ep about t he m echanics of writ ing filt ers and t hen we can t urn t o t he act ual filt ers t hem selves. How do we t ell TCPdum p t o perform t he AND operat ion and wit h what value? First , we want t o represent t he m ask byt es as t wo hexadecim al charact ers. 0000 1111 can be t ranslat ed t o 0x0f. The 0x inform s TCPdum p t hat t his value is in hexadecim al; it s default base is decim al. Here is how t o const ruct t he part ial filt er:

ip[0] & 0x0f

This says t o t ake t he value found in t he 0 byt e offset of t he I P header and AND it wit h a hexadecim al value of 0f. Pu t t in g I t All Toge t h e r We are dealing wit h t he 0 byt e offset of t he I P header. We AND t hat byt e wit h a hexadecim al 0x0f and we have j ust m anaged t o focus on t he I P header lengt h. Why m ight you want t o isolat e t his field? One very good reason is t o t est for t he presence of I P opt ions. The norm al I P header is 20 byt es, or five 32- bit words. That m eans t hat an I P header t hat m ight cont ain a dangerous I P opt ion such as source rout ing would have a lengt h of great er t han 5 found in t his field. I P opt ions are alm ost never used any m ore for anyt hing ot her t han evil int ent , so we want t o know whet her I P opt ions exist . Recall from t he TCPdum p filt er synt ax t hat you need a relat ion and a value. The ent ire filt er t o find a signat ure of an I P dat agram t hat has I P opt ions is as follows:

ip[0] & 0x0f > 5

That is it . The end of a very long st ory. I know t his seem s like a lot of work and a lot of t heory, but it t ruly does get easier as you get m ore pract ice. I warned you about t he t inkering part ; if you followed t his and t hink you underst and, however, you're well on your way t o exam ining any field including bit s of t he I P dat agram . Not m any int rusion- det ect ion syst em s offer t his capabilit y. Wit h TCPdum p, you lose no fidelit y in your abilit y t o capt ure and analyze dat a. Again, not m any int rusion- det ect ion syst em s can m ake t his claim . That is why it m ight be wort h your while t o becom e fam iliar wit h TCPdum p and TCPdum p filt ers.

TCPdu m p I P Filt e r s Som e of t he t ellt ale indicat ions in t he I P header t hat you m ight be a t arget of reconnaissance include t raffic sent t o your broadcast addresses, fragm ent at ion, and t he presence of I P opt ions. You should never see legit im at e t raffic sent t o your broadcast addresses from out side your net work, and you should block t his t raffic as previously m ent ioned t o prevent t he likes of m apping and Sm urf at t acks. As you learned, fragm ent at ion is a nat ural enough byproduct of a dat agram t raveling t o a net work t hat originat ed on a net work wit h a larger MTU. But , you also saw how fragm ent at ion can be used for denial- of- service at t acks or t o t ry t o bypass not ice by an I DS or rout ers t hat cannot keep t rack of st at e. D e t e ct in g Tr a ffic t o t he Br oa dca st Addr e sse s Let 's define t he broadcast address as one wit h a final oct et of 255 or 0. This includes m ost broadcast addresses subdivided on classic byt e boundaries. Take a look again at Figure 12.1. The dest inat ion address is found in byt es 16 t hrough 19 ( 32 bit s) of t he I P header. We are only concerned wit h t he final oct et , or byt e 19. We can describe t he broadcast addresses as follows:

ip[19] = 0xff ip[19] = 0x00

or as a com bined filt er as follows:

ip[19] = 0xff or ip[19] = 0x00

We t end t o express ourselves in hexadecim al and not decim al, but you could have as easily writ t en t his filt er:

ip[19] = 255 or ip[19] = 0

Depending on where t he sensor host is t hat runs t he TCPdum p filt er, you m ight

pick up broadcast t raffic inside your net work. Assum e, for exam ple, t hat your inside net work is 192.168.x.x. To furt her qualify t his filt er t o exam ine only t raffic direct ed t oward your net work from a foreign source, you t weak t he filt er as follows:

not src net 192.168 and (ip[19] = 0xff or ip[19] = 0x00)

The preceding int roduced a new operat or, t he not, t o negat e; and a couple of new m acros: src, t o indicat e t he t raffic originat ed from t his source, and net t o indicat e a subnet . This filt er says you want t o look at any t raffic t hat originat es from a source net work ot her t han your own t hat is dest ined for t he broadcast addresses. I f you st art TCPdum p wit h t his filt er or collect TCPdum p dat a and lat er read it back wit h t his filt er, it picks up at t em pt ed m apping effort s of your net work. D e t e ct in g Fr a gm e n t a t ion I n t his sect ion, you exercise som e of your new knowledge of t he m echanics of writ ing TCPdum p filt ers t o look for fragm ent at ion. All fragm ent s in a norm al fragm ent t rain except t he last one have t he m ore fragm ent s bit set . I f you can discover how t o locat e t his field and see whet her it is set , you can find m ost of t he fragm ent ed t raffic direct ed your way. Look again at Figure 12.1. You see t hat t he m ore fragm ent s bit is in t he second row of t he I P header. Can you figure out what byt e it is in? Specifically, if you count int o t he I P header, you will find it in t he 6 t h byt e offset . I t is t he t hird bit from t he left of t he high order- bit . Look at Figure 12.3 t o see how you m ight m ask all surrounding bit s except t his one. Your m ask needs t o be 0010 0000, which is a hexadecim al 0x20. Your filt er becom es ip[ 6] & 0x20 ! = 0. You use a generic relat ion and value of ! = 0. This m eans t hat t he m ore fragm ent s bit is set . Why not j ust say ip[ 6] & 0x02 = 1? Aft er all, aren't you t est ing t hat t he exact bit is set ? Not really. The problem wit h t his is t hat you are not t est ing t he bit value, but t he result ing value of m asking t he original byt e and t he m ask byt e. Therefore, you need t o exam ine t he result ing value in cont ext of where it falls in t he whole byt e. I f t he m ore fragm ent s bit is set , it falls in t he byt e in t he 2 5 posit ion of t he byt e, which is 32. A generic ! = 0 is a lit t le easier t o express t he result . Alt ernat ively, you can writ e t he filt er as ip[ 6] & 0x02 = 32. Keep in m ind t hat because fragm ent at ion is not always m alicious, you are likely t o generat e false posit ives wit h t his filt er. Figu r e 1 2 .3 . I de n t ifyin g t h e m or e fr a gm e n t s bit .

You have now seen how t o express t hree TCPdum p filt ers for pot ent ially anom alous set t ings in t he I P header. Now, t urn your at t ent ion t o som e of t he ot her prot ocols and how you can use TCPdum p filt ers t o discover ot her sort s of event s of int erest .

TCPdu m p UD P Filt e r s Many backdoors and Troj ans use UDP port s, such as port 31337 used by Back Orifice. To det ect UDP connect ions, you m ust decide on which UDP port s you want t o exam ine direct ed act ivit y. Take a look at www.snort .org/ port s.ht m l for an idea of som e of t he t ypes of port s you m ight want t o wat ch. Configure your filt ers t o wat ch for act ivit y t o t hese port s. I f you want t o look for t raffic t o Back Orifice, for exam ple, your filt er is as follows:

udp and dst port 31337

The labor is not in figuring how t o express t his as a TCPdum p filt er; as you see, it is t rivial. The labor is involved in deciding which port s you want t o include, adding t hem t o t he filt er, and keeping t he filt er current wit h t he real world of everexpanding UDP exploit s. Consider a popular UDP applicat ion, t racerout e. The UNI X t racerout e works by at t em pt ing t o send UDP dat agram s t o high- num bered port s of t he dest inat ion host . I f a host on your net work is t hat dest inat ion host , you want t o be alert ed of t he at t em pt ed or successful t racerout e. I f you begin by looking at UDP act ivit y t o port s in t he 33000–33999 range, you will find m ost of t he t racerout e act ivit y. Be warned t hat Windows t racerout es use I CMP echo request s and replies, so t his signat ure does not det ect t hat act ivit y. And, be forewarned t hat som e versions of t he UNI X t racerout e enable t he user t o provide com m and- line opt ions, one of which is a dest inat ion port . Therefore, t his filt er m ight not capt ure all t racerout e act ivit y, but it will find m ost of t he convent ional act ivit y. Figure 12.4 shows t he layout of t he UDP header. Not ice t hat t he UDP dest inat ion port num ber is found in byt es 2 and 3 of t he UDP header. Figu r e 1 2 .4 . Th e UD P h e a de r .

A very insight ful quest ion t o ask is t his: " Why don't we use t he port m acro rat her t han byt e displacem ent s?" For inst ance, why can't we use t his filt er:

dst port >= 33000 and dst port < 34000

The problem is t hat when TCPdum p uses a range such as t his and not one exact value, you have t o express t hat field in t erm s of t he prim it ive prot ocol and displacem ent and forgo t he use of m acros. The correct synt ax t o discover t racerout es t hen becom es t his:

udp[2:2] >= 33000 and udp[2:2] < 34000

Not ice t he first use of t he lengt h opt ion [2:2] t o span byt es. You need t o exam ine t wo consecut ive byt es st art ing at byt e 2 offset . You can furt her lim it t he am ount of t raffic t hat t his filt er ext ract s by exam ining t he TTL value along wit h t he dest inat ion port . Tracerout e operat es by m anipulat ing t he TTL value found in t he I P header. Tracerout e records t he rout ers t hat it t raverses and does so using an increm ent ing TTL value. More oft en t han not , you will see a TTL of 1 on t he sensor host running TCPdum p before it crosses a rout er t hat will expire it . This is a signat ure of t racerout e. Therefore, let 's em bellish t he t racerout e filt er t o include t he TTL value t o elim inat e som e of t he noise associat ed wit h discovering t racerout es. The TTL field is found in t he I P header; it has no m acro t o reference it and if you look once again at Figure 12.1, you find it in t he 8 t h byt e offset . Here is what t he new filt er would look like:

udp[2:2] >= 33000 and udp[2:2] < 34000 and ip[8] = 1

This gives you an idea of som e of t he UDP filt ers. TCPdum p filt ers can also be used for I CMP t raffic. Specifically, som e of t he good candidat es for det ect ion of anom alous I CMP t raffic are address m ask request s, som eone t rying t o discover t he MTU of your net work sending dat agram s wit h t he don't fragm ent bit set and receiving back m essages from your rout er wit h t he MTU, and Loki. All t hese filt ers are so sim ple t o writ e. We will leave t hese for you t o t ry. Here are t he signat ures of TCPdum p filt ers for you t o writ e on your own: z

z

z

The address m ask request has a value of 17 in t he 0 byt e offset of t he I CMP m essage. The fragm ent at ion required, but DF flag set m essage has a 3 in t he 0 byt e offset of t he I CMP m essage and a 4 in t he 1 st byt e offset of t he m essage. A signat ure for Loki was an echo request ( an 8 in t he 0 byt e offset of t he

I CMP m essage) or an echo reply ( a 0 in t he 0 byt e offset of t he I CMP m essage and in t he 6 t h and 7 t h byt es offset of t he I CMP m essage) . You would have a hexadecim al value of 0xf001 or 0x01f0. Answers t o I CMP filt ers:

- icmp[0] = 17 - ((icmp[0] = 3) and (icmp[1] = 4)) - (((icmp[0] = 0) or (icmp[0] = 8)) and ((icmp[6:2] = 0xf001) or (icmp[6:2] = 0x01f0)))

TCPdu m p TCP Filt e r s TCPdum p filt ers for TCP t raffic are m ost ly concerned wit h init ial SYN connect ions and ot her t ypes of anom alous flag com binat ions t hat m ight indicat e som e kind of reconnaissance or m apping effort s. We want t o look for init ial SYN connect ions because t hey inform us of at t em pt ed connect ions t o a TCP port . This doesn't necessarily m ean t hat t hey were successful. I f your TCPdum p sensor is locat ed out side a packet - filt ering device t hat blocks access t o t he TCP dest inat ion port , it will never reach t he host . And, if t he t raffic is allowed t hrough t he packet - filt ering device, it is possible t hat t he host doesn't offer t he at t em pt ed service. You can glean a lot of int elligence by det ect ing t his act ivit y, t he least of which is discovering rogue TCP port s t hat host s on your net work m ight be offering. Filt e r s for Ex a m in in g TCP Fla gs Figure 12.5 relat es t o m ost of t he rem aining filt ers in t his chapt er. Figu r e 1 2 .5 . Th e TCP fla g byt e .

The TCP flag bit s are locat ed in t he 13 t h byt e offset of t he TCP header. Because you are looking for individual bit s in t he byt es, you need t o perform som e bit m asking t o select t he flag or flags you want t o exam ine. Begin by writ ing a filt er t o ext ract records wit h t he SYN flag alone set :

tcp[13] & 0xff = 2

Why t his filt er? We see t hat our m ask consist s of all 1s. Why didn't we use a m ask of 0s in all fields except t he SYN flag ( t cp[ 13] & 0x02 = 2) ? By m asking a bit wit h a 0, t he result ing value is necessarily 0. The value bit could be 1, however, and t he 0 m ask would discard it . I f t his is confusing, t ry an exam ple. Suppose t hat you want t o look at TCP segm ent s wit h t he SYN flag alone set . Okay, now suppose t hat you have a TCP flag byt e wit h bot h t he SYN and ACK flags set . The binary value t hat you would see for t he TCP flag byt e would be 0001 0010. I f t hat were m asked wit h 0000 0010, you would end up wit h a result of 0000 0010, which is 2. Therefore, m asking wit h 0s in fields ot her t han t he SYN flag select s TCP segm ent s wit h ot her flags set along wit h t he SYN flag. To prevent t his from occurring, you use t he original filt er and preserve all t he value bit s; t he result ing value will not be 2 if any ot her value bit is set . I f t he ACK bit were set , you would have a result ing value of 18 from t he new m ask. This filt er does not select records wit h ot her flags set along wit h t he SYN flag. Because you are looking for t he SYN flag alone set , t o be perfect ly sim ple about t his part icular filt er, you can specify it by:

tcp[13] = 2

This will assure t hat only t he SYN flag is set because if any ot her flag is set , t he result ing value when adding up all t he bit s set in t he byt e will not be 2. For inst ance, let 's say t hat you have a byt e wit h an errant SYN and URG flag set t oget her. The URG flag is found in t he posit ion of t he byt e t hat has a value of 32 and t he SYN flag is found in a posit ion wit h a value of 2. Therefore, t he result ing com bined value of t hese t wo bit s set would be 34 and would not m at ch t he filt er. Take a look at som e ot her TCP flag com binat ions you m ight want t o know about : z

z

z

t cp[ 13] & 0xff = 0 alt ernat ively t cp[ 13] = 0 This shows null scans wit h no flags set . This condit ion should never occur. t cp[ 13] & 0xff = 3 alt ernat ively t cp[ 13] = 3 This shows act ivit y where bot h t he SYN and FI N flags are set sim ult aneously; t his is definit ely an anom alous condit ion. You m ight want t o alt er t he filt er t o t cp[ 13] & 0x03 = 3, because t his get s any act ivit y wit h bot h t he SYN and FI N flags set , as well as any ot her flags set . I n t his case, you don't necessarily want t o exclude t his t o SYN and FI N alone. t cp[ 13] & 0xff = 0x10 and t cp[ 8: 4] = 0 This shows act ivit y wit h t he ACK flag set , but wit h an acknowledgem ent value of 0. This is usually an anom alous condit ion because t he t hree- way handshake necessarily consum es a sequence num ber. Logically, an acknowledgem ent value would have t o be 1 great er t han t he init ial sequence num ber m eaning it will be non- zero. This

filt er is offered because it oft en capt ures nm ap operat ing syst em fingerprint ing scans t hat send TCP t raffic t o various dest inat ion port s wit h t he ACK flag alone set , but a 0 value in t he acknowledgem ent field. I t is rarely possible t hat a 0 acknowledgem ent can be legit im at e if t he sender has sent a sequence num ber where all t he bit s in t he sequence num ber are 1 – in ot her words 2 32 – 1. The next expect ed sequence num ber would t hen wrap around and be 0. z

t cp[ 13] > = 64 Figure 12.5 shows t wo high- order bit s in t he TCP flag byt e t hat are labeled reserved bit s. These t wo bit s should be 0s; if t hey are not , som et hing m ight be am iss. The first reserved bit is found in t he 2 6 ( 64) posit ion, and t he second is found in t he 2 7 ( 128) posit ion. I f eit her or bot h bit s are set , t he value for t he TCP flag byt e is great er t han or equal t o 64. Our old friend nm ap som et im es set s t he bit t hat is in t he 64 posit ion t o perform operat ing syst em fingerprint ing. Most host s reset t hese values t o 0s, but som e leave t he set value. This is used by nm ap t o help classify t he operat ing syst em behavior. More recent ly, t hese erst while- reserved high- order TCP flag bit s are now associat ed wit h som et hing known as Explicit Congest ion Not ificat ion ( ECN) . This is a t echnique for reducing congest ion in a net work. How can you dist inguish legit im at e ECN t raffic from nm ap operat ing syst em scans? ECN t raffic should have a non- zero value in t he different iat ed services byt e ( form erly known as t he t ype of service byt e) , whereas nm ap will have a 0 in t his field. I f you care t o read m ore about ECN, reference RFC 3168.

These are j ust som e of t he different com binat ions of TCP flags t hat you can exam ine. This is not an exhaust ive list and I encourage you t o play wit h t hese filt ers and develop different com binat ions. D e t e ct in g D a t a on SYN Con n e ct ion s Before let t ing you loose t o develop som e TCPdum p filt ers of your own, let 's t ake a look at one advanced filt er t hat will sum m on up all t he various bit s and pieces you have learned in t he chapt er about developing filt ers and t hen som e. I n Chapt er 2, " I nt roduct ion t o TCPdum p and TCP," you learned t hat dat a should not be sent before t he t hree- way TCP handshake has been com plet ed. You saw t his act ivit y wit h t he 3DNS product , which is a nuisance but ost ensibly not m alicious. You also read about t he exam ple of a scan t hat a sit e received in which t here was dat a included on t he SYN. I t was feared t hat t his t ype of act ivit y m ight be an at t em pt t o elude an I DS t hat st art ed st ream or dat a assem bly for dat a received aft er t he t hree- way handshake only. I t seem s prudent t hen t o t ry t o develop a TCPdum p filt er t hat would det ect t his act ivit y. You could lat er put in exclusions for annoying false alarm s from 3DNS

act ivit y. The problem is t hat no field in t he TCP header has t he num ber of byt es in t he TCP payload. You do have a bevy of ot her fields t hat have lengt h values in t hem , however. Specifically, in t he I P dat agram , you have t wo lengt h fields in t he I P header. One is t he lengt h of t he ent ire I P dat agram , and t he ot her is t he lengt h of t he I P header alone. I n t he TCP segm ent , you have t he lengt h of t he TCP header. Figure 12.6 shows t hat t he lengt h of t he I P dat agram m inus t he lengt h of t he I P header m inus t he lengt h of t he TCP header should leave t he TCP payload lengt h. Figu r e 1 2 .6 . Ca lcu la t in g t h e TCP pa yloa d le n gt h .

" Piece of cake," you say? You will encount er som e com plicat ions, or challenges ( your choice) . Not ice t he different m et rics in different fields; t he I P dat agram lengt h is in byt es, whereas t he I P header and TCP header are in 32- bit words. You m ust st andardize t o byt es and convert t he header lengt hs t o byt es by m ult iplying t hem by a fact or of 4. This is quit e m anageable. You have already dealt wit h t he I P header lengt h, and so you have pret t y m uch conquered t hat . One final bit of nast iness t hat you need t o address is t he TCP header lengt h seen in Figure 12.7. Look carefully at where t his is locat ed; it is in t he high- order nibble of t he 12t h byt e. You already know t hat you have t o zero- out t he low- order nibble t o deal wit h t he high- order nibble exclusively, but you aren't quit e ready t o t ackle t he form ula j ust yet . Because t his is in t he high- order nibble, it is really m ult iplied by a fact or of 16, so it has t o be norm alized. Figu r e 1 2 .7 . Th e TCP h e a de r .

Suppose, for exam ple, t hat you have a TCP header lengt h of 24 byt es t hat includes a 20- byt e header and som e TCP opt ions. Rem em ber t hat you have t o convert t o 32- bit words, so you need t o divide by 4 t o com put e t he value t hat would be found in t he TCP header lengt h field. You would find a value of 6 in t his field. Assum e you have also m asked t he low- order nibble so t hat t he hexadecim al value rem aining in t his byt e is 60. The binary represent at ion of t his byt e is 0110 0000. A 1 is in t he 2 6 posit ion ( 64) and a 1 is in t he 2 5 posit ion ( 32) , which really m eans you have 96. Because t his field is in t he high- order nibble, it is really 16 t im es a value found in a low- order nibble. To norm alize t his back t o 6, you need t o divide by 16. Sum m ing up all t he m anipulat ions t o t his field, you want t o norm alize by dividing by 16 and t hen convert t o byt es by m ult iplying by 4. Now you are ready t o t ackle t his filt er. Let 's revisit t he condit ions and form ula we want in pseudo- code before at t em pt ing t he TCPdum p filt er. I f t he SYN flag alone is set , subt ract from t he I P dat agram t ot al lengt h, t he I P header lengt h convert ed t o byt es, and t he TCP header lengt h norm alized and convert ed t o byt es, and check t o see whet her t he result ing value is non- 0. SYN flag alone is set :

tcp[13] & 0xff = 2

or alternatively tcp[13] = 2

Tot al lengt h of t he I P dat agram :

ip[2:2]

I P header lengt h convert ed t o byt es:

((ip[0] & 0x0f)*4)

TCP header lengt h norm alized and convert ed t o byt es:

((tcp[12] & 0xf0)/16*4)

which is t he sam e as:

((tcp[12] & 0xf0)/4)

Now put it all t oget her t o see t he final filt er:

tcp[13] & 0xff = 2 and ( ip[2:2] ((ip[0] & 0x0f)*4) ((tcp[12] & 0xf0)/4) ) != 0

This discovers any t raffic t hat at t em pt s t o include dat a on t he init ial SYN. Pret t y awesom e!

Su m m a r y This chapt er has shown t hat alt hough TCPdum p filt ers m ight not win m ost - likelyt o- succeed in a beaut y pageant of I DS filt ers, t hey can do som e am azing t hings. Yes indeed, you need t o get your hands soiled and you need t o t hink pret t y darn hard m any t im es when at t em pt ing t o debug a filt er t hat does not work. But , t hese filt ers give you full access t o your dat a. I cannot em phasize enough t hat when you sm ell som et hing foul wit h your dat a, you want t he abilit y t o analyze at t he bit level. TCPdum p filt ers afford you t his power. Lit erally, you want t o leave no bit unt urned when you are conduct ing in- dept h analysis. Most of t he filt ers t hat you writ e using TCPdum p will probably use m acros and probably won't require any bit m asking. When you need t o exam ine individual bit s or disj oint bit s in a byt e, however, you m ust isolat e t he bit s of int erest using bit m asking. The ot her got cha wit h TCPdum p discussed in t his chapt er is st andardizing on m et rics wit h different lengt h fields—m ake sure you convert t o

byt es. Finally, rem em ber t hat t he locat ion where bit s fall in t he byt e is significant . I t m ight be necessary t o norm alize if you are dealing wit h bit s in t he high- order nibble. I f you are up t o t he challenge of all of t his, I t hink you will get a t rue sense of sat isfact ion aft er you have m ast ered t he deciphering of dat a and t he creat ion of pot ent ially revealing filt ers.

Ch a pt e r 1 3 . I n t r odu ct ion t o Sn or t a n d Sn or t Ru le s

Snort is an open source free NI DS t hat was developed by Mart y Roesch. I t was init ially writ t en so t hat Mart y could do t raffic sniffing at his j ob and has grown t o a full- feat ured NI DS. Along t he way, Mart y has at t ract ed a vast following of adm irers and coders who work collect ively t o enhance t he code and issue new releases. I n early 2002, Snort was downloaded from it s hom e at ht t p: / / www.snort .org/ over 10,000 t im es a week t o prot ect governm ent , corporat e, hom e, and educat ional sit es. Snort is a signat ure- based NI DS t hat uses a com binat ion of rules and preprocessors t o analyze t raffic. The rules offer a sim ple and flexible m eans of creat ing signat ures t o exam ine a single packet . The preprocessor code allows m ore ext ensive exam inat ion and m anipulat ion of dat a t hat cannot be done via rules alone. Preprocessors can perform a variet y of t asks such as I P defragm ent at ion, port scan det ect ion, web t raffic norm alizat ion, and TCP st ream reassem bly, t o nam e a few. Preprocessors give Snort t he capabilit y t o look at and m anipulat e st ream s, as opposed t o t he single- packet - at - a- t im e view rules use. The current version of Snort in March 2002 is 1.8.3 and is a com pact 1.8 m egabyt es of source code. I t is ext rem ely port able and current ly runs on approxim at ely 23 different plat form s including Linux, Solaris, BSD, I RI X, HP- UX, Mac OS X, and Win32. Snort is also easily configurable and flexible, allowing users t o creat e t heir own signat ures and alt er t he base funct ionalit y t hrough t he use of plug- ins. Plug- ins are code t hat can opt ionally be com piled int o Snort at inst allat ion t im e and offer feat ures such as act ive response t o m alicious t raffic. The focus of t his sect ion of t he book is writ ing filt ers and signat ures, so m any aspect s of Snort will not be discussed, such as inst allat ion, configurat ion, and out put . I f you would like m ore inform at ion on t hese t opics about Snort , please

visit ht t p: / / www.snort .org/ . This chapt er will cover an int roduct ion t o Snort , t he anat om y of a Snort rule, and explore fields and possible values found in t he first part of a Snort rule known as t he rule header. The next chapt er will cont inue rule writ ing by discussing t he second part of t he rule known as t he rule opt ions. I t will also cover writ ing m ore advanced rules.

An Ove r vie w of Ru n n in g Sn or t Snort can be run in various m odes from sim ply dum ping sniffed t raffic t o t he screen, t o NI DS m ode where Snort is able t o com pare t he net work t raffic wit h a preconfigured set of signat ures known as rules t hat are housed in one or m ore files. The lat t er is t he m ost com m on m ode in which t o run Snort . Snort is t ypically run from t he com m and line, whet her it is run on a UNI X or Windows host . There is soft ware offered known as I DScent er, which provides a Windows GUI int erface, as well as Dem arc/ Puresecure, which provides a Windows and UNI X GUI int erface. There are m any com m and- line opt ions t hat can be used, but t he m ost pract ical one ( - c snort .conf) allows t he user t o place Snort in NI DS m ode by inform ing it of t he configurat ion file t o be used. As t he nam e im plies, t his is where Snort configurat ion occurs, including assigning variables used in t he rules values, inform ing Snort which preprocessor opt ions t o use, and t elling Snort which rules t o include in t raffic analysis. A skelet on configurat ion file nam ed snort .conf is provided in t he Snort download direct ory. The user m ust cust om ize t his file for his sit e. When Snort is run in NI DS m ode, by default , it places t he out put of event s of int erest t riggered by t he rules in various files. Snort allows an act ion t o be assigned t o each rule, indicat ing what t o do when t he rule is t riggered. An act ion of alert m eans t o writ e t he offending packet t o a file nam ed alert , which is creat ed in / var/ log/ snort on m any UNI X host s, by default . On Windows host s, t he alert file is creat ed in t he log subdirect ory in t he current direct ory from which Snort is run. Here is an exam ple of a Snort alert file ent ry:

[**] NMAP TCP ping [**] 03/21-13:33.51:880120 1.2.3.4:1029 -> 192.168.5.5:80 TCP TTL:46 TOS:0x0 ID:19678 ******A* Seq: 0xE4F00003 Ack: 0x0

Win: 0xC00

There is an ident ifying m essage associat ed wit h t he alert t hat t he user can assign when t he rule is creat ed. This is opt ional; however, it inform s t he analyst of t he perceived problem . The m essage for t he preceding alert is "NMAP TCP ping" . On t he next line, t here is a dat e and t im est am p followed by source I P address ( 1.2.3.4) and port ( 1029) , direct ion of t he t raffic ( source t o t he left of t he arrow and dest inat ion t o t he right of t he arrow) , and t he dest inat ion I P address ( 192.168.5.5) and port ( 80) of t he offending packet . The t hird line indicat es t hat

t he t raffic is TCP, it has an arriving t im e- t o- live value of 46, a t ype of service value of 0, and an I P ident ificat ion num ber of 19678. The final line list s t he TCP flags set ; t he A signifies t hat t he acknowledgem ent flag is set . I t is followed by a hexadecim al represent at ion of t he TCP sequence num ber, t he acknowledgem ent num ber, and t he TCP window size. All of t hese fields can provide m ore det ails about t he packet t hat t riggered t he alert . This alert appeared because t here is a rule t hat exam ines TCP segm ent s wit h an acknowledgem ent flag set but an accom panying acknowledgem ent value of 0. Most of t he t im e when t his is observed, it is a t ellt ale sign of nm ap at t em pt ing t o discover a live host . I f t he acknowledgem ent is allowed t o reach t he dest inat ion host , t he host should respond t o t he unsolicit ed acknowledgem ent wit h a reset , regardless of whet her t he port is list ening or not . That is why t he m essage accom panying t he alert is " NMAP TCP ping." The alert act ion causes t he act ivit y t o be logged as well. There is a separat e act ion, log, which only logs t he t riggered act ivit y. When act ivit y is logged, it is recorded in a hum an readable form at t hat can provide m ore verbose inform at ion about t he packet , such as t he payload. The logged packet s are writ t en t o files and direct ories based on t he I P addresses in t he packet being logged. These are furt her segregat ed by t he t ransport layer prot ocol and source and dest inat ion port s involved in t he connect ion. Look at t he cont ent s of FTP act ivit y t hat was logged:

[**] Attempted anonymous ftp access [**] 04/24-12:11:08.724441 192.168.143.15:3484 -> 192.168.143.16:21 TCP TTL:64 TOS:0x10 ID:30124 DF *****PA* Seq: 0x93EE0AB7 Ack: 0xB8352E61 Win: 0x7D78 TCP Options => NOP NOP TS: 112024246 27551686 55 53 45 52 20 61 6E 6F 6E 79 6D 6F 75 73 0D 0A USER anonymous..

The logged out put cont ains t he sam e inform at ion t hat t he alert does, but it also has t he payload if t he decode ( - d) com m and- line opt ion was supplied. This m essage indicat es t hat we have a rule t o inspect ft p com m and- line t raffic t o dest inat ion port 21 for a user of anonym ous. We will exam ine how t his is accom plished in Chapt er 14, " Snort Rules—Part I I ," but t he payload from t he previous out put indicat es t hat t here was an anonym ous user at t em pt . The hexadecim al represent at ions of t he ASCI I values in t he payload are also included in t he logged packet . The log and alert files can be a cum bersom e way of analyzing out put from Snort , so it allows you ot her opt ions via configurat ion file changes. Act ivat ing available out put opt ions can enable writ ing out put or alert s t o spool files via a backend known as Barnyard, or direct ly t o a dat abase, t o nam e a few of t he possible opt ions.

Sn or t Ru le s Snort support s bot h header and payload inspect ion m et hods, allowing you t o fully specify in a single rule what is considered a suspect packet . This flexibilit y allows you t o build rules cust om ized t o your sit e t hat great ly aid in m inim izing false posit ives, but in a form at t hat is very readable. Rem em ber all t he heart ache and t oil involved in writ ing TCPdum p filt ers, especially one t o inspect a packet for a part icular TCP flag set t ing? Well, writ ing an ident ical rule in Snort is alm ost t rivial, as you will soon see. As a short but im port ant digression, what qualit ies does one look for in a good NI DS? There are m any, but one of t he m ost im port ant is t he capabilit y t o inspect and alt er signat ures. Believe it or not , t here are NI DS available t hat do not allow t he user t o see t he act ive signat ures or alt er t hem in any way. This blindsides t he analyst and does not allow her t o dist inguish bet ween false posit ives and real alert s. When an alert appears, it is present ed as an irrefut able st at em ent t hat a problem has appeared, and t here is no way t o validat e it using t he NI DS alone. I f t he analyst can exam ine t he signat ures and t he packet t hat caused t he alert , t here is a bet t er chance t hat a m ore accurat e assessm ent can be m ade. Addit ionally, signat ures t hat allow an analyst t o look at any field, eit her header or payload, from different perspect ives pot ent ially im prove t he qualit y of t he NI DS. I n ot her words, if a NI DS only allows t he analyst t o creat e rules t hat inspect packet s for a given I P or port or prot ocol, it lacks t he range t o exam ine payloads or header fields on a m ore granular level such as TCP flag set t ings. Perhaps t he analyst is int erest ed in inspect ing t he payload for specific cont ent s when t he acknowledgem ent flag is set . Because ot her flags m ay be set along wit h t he acknowledgem ent flag, it would be handy for t he signat ure t o allow for t his specificat ion as well. The capabilit y t o inspect j ust about any field in a packet is an area in which Snort excels. There are m any opt ions available t o configure a rule t o specify j ust about any field in t he packet and exam ine t he value of t hat field in a variet y of ways. And, t he few fields t hat cannot be inspect ed via current Snort rule opt ions can always be exam ined by supplying a filt er at t he end of t he com m and line or by resort ing t o a com m and- line swit ch ( - F) t hat allows Berkeley Packet Filt ers ( BPF) t o be specified in a file. Berkeley Packet Filt ers are what we have been calling TCPdum p filt ers, which can be used t o select t he desired field. For inst ance, Snort doesn't have an opt ion t o exam ine t he I P version field found in t he high- order nibble of t he zero byt e offset of t he I P header. Snort m ight be run t o exam ine packet s off t he wire or from a binary file of capt ured TCPdum p dat a using a BPF filt er t o find any packet s wit h an I P version t hat does not equal 4. Here is t he com m and t hat would perform t his inspect ion reading packet s from t he net work:

snort –v 'ip[0] & 0xf0 != 0x40'

As explained in m ore det ail in Chapt er 12, " Writ ing TCPdum p Filt ers," t his will m ask out t he low - order nibble of t he zero byt e offset of t he I P header and look for a value of 4 in t he high- order nibble of t hat field and writ e t he out put t o t he screen ( - v) . Anot her benefit of using Snort is t hat it com es wit h a very large set of rules. I t is not recom m ended t hat all of t he rules be used on inst allat ion because t he m ore act ive rules used, t he slower t he t raffic inspect ion becom es. The analyst m ust decide which rules are appropriat e for t he sit e. And, am azingly, new Snort rules are released som et im es as soon as hours aft er a new exploit is discovered. This is by virt ue of having so m any savvy users and developers of Snort who respond alm ost inst ant ly t o develop and t est new rules for t hese exploit s. However, a word of caut ion m ust be added about som e Snort rules. Just because a rule becom es available short ly aft er an exploit is released, doesn't m ean t hat it is a good rule—t hat is t o say, j ust because a rule m at ches a given com piled version of an exploit 's out put doesn't m ean t hat it is necessarily a rule t hat m ay find variat ions of t he exploit from m aking m inor changes in t he source code. I t is im perat ive t hat t he rule writ er underst ands not only t he exploit code and out put , but also t he prot ocol against which it runs. A good rule anchors on fields and values t hat m ust rem ain st at ic for t he exploit t o succeed. For inst ance, if t here is som e kind of DNS exploit t hat generat es a DNS ident ificat ion num ber of 0xBEEF, t his is not a good field or value t o use in t he rule. I t is t rivial t o change t his in t he source code, and t he exploit will m ost likely succeed regardless of t he value of t he DNS ident ificat ion num ber.

H idde n Sign a t u r e s As a cont ract or for a client , I once had t he opport unit y t o visit a com m ercial NI DS vendor about int egrat ing out put from it s NI DS t o som e kind of correlat ion t ool. Frankly, I believed t he out put from t he NI DS wasn't wort h t rying t o correlat e since t here was no way t o validat e if t he generat ed alert s were real because t here was no access t o eit her t he signat ures or t he packet s t hat caused t he alert . Why synt hesize garbage? But , t he client had request ed m y presence at t he m eet ing, so I dut ifully at t ended. While t here, I asked if t here was any way t hat we could get access t o t he signat ures. The vendor rep balked and asked why I would ever need t o see t he signat ures. " Well, I want t o know if we have a real det ect or false posit ive," I polit ely responded. The rep replied t hat if I believed we had seen a rare false posit ive, I could call t he support line and ask for help. Wit h t he num ber of false posit ives generat ed by t he vendor's NI DS, I could only im agine t hat it had st ock in t he Baby Bells t o answer so foolishly. I ndignant ly, I pressed on and asked t he rep what t he problem

was wit h releasing his signat ures. The response was t hat if I could see t he signat ures, so could t he hackers! Honest t o goodness, t hat was t he best dog- at e- m y- hom ework excuse he could com e up wit h. More t han anyt hing, I suspect it was t hat he feared t hat t he com pet it ion m ight pirat e his product 's signat ures, but he didn't have t he spine t o say t hat . How are you supposed t o t ake t hese guys and t heir propriet ary signat ures seriously? Okay, so we're not all blessed wit h t he power t o eit her m ake or influence t he decision of which NI DS t o buy. What if you happen t o work at a sit e where you have a NI DS t hat has eit her a lim it ed or no view of t he signat ures and t raffic—do you t hrow in t he t owel? Well, if lobbying for a bet t er NI DS fails, you can becom e resourceful! You can always run TCPdum p in t he background m ode eit her alone or as part of Shadow. Or, you can t ry t o do correlat ion wit h ot her sources of inform at ion such as firewalls, rout ers, or host logs. This is not ideal, but it prevent s you from being t ot ally blind. We were running Shadow along wit h t he deficient NI DS m ent ioned previously. An analyst called m e t o report t hat t he NI DS was alert ing on a Loki at t ack and asked if I could exam ine t he TCPdum p out put t o discover whet her t his was a real alert or not . I knew t hat Loki had a t ellt ale signat ure years ago of a value of 0xf001 or 0x01f0 in t he I CMP sequence num ber. The analyst was able t o give m e t he source and dest inat ion I P num bers for t he suspect ed Loki t raffic. I searched t he TCPdum p records and discovered I CMP packet s t hat m at ched t he signat ure; however, t his was j ust a case of coincident al use of t hose values in t he I CMP sequence num ber in an innocuous I CMP echo request / response pair. This was an awkward and t im e- consum ing way of dealing wit h t his false posit ive, but it was bet t er t han put t ing full t rust in t he NI DS. Snor t Rule An a t om y An individual rule is broken int o t wo general part s. The first part , t he rule header, defines who m ust be involved in order for t he t raffic t o be considered by t he rule opt ions. The second part , t he rule opt ions, defines what m ust be involved. This includes packet header inform at ion ( such as TCP flag set t ings) or t he cont ent s of t he payload. Generally speaking, bot h sect ions are used for m ost rules. I t is possible t o specify rules wit h only a rule header so t hat t he given act ion can be t aken for t he provided host s and port s. This is t ypically t he case where pass rules are used t o ignore t raffic bet ween specific host s and port s, such as port 53 t raffic com ing from a sit e's DNS servers. All condit ions specified in bot h t he rule header and t he rule opt ions m ust be t rue in order for an alert or som e ot her kind of act ion t o be t riggered. I t is also im port ant t o underst and t he Snort rules are st at eless. I n ot her words, each rule inspect s one

and only one packet . The rules t hem selves have no way of knowing what act ivit y occurred in a packet preceding or following t he current one. Snort at t em pt s t o build in funct ionalit y for st at e using a preprocessor such as I P defragm ent at ion or TCP st ream reassem bly, but t here are lim it s t o what can be discovered when not exam ining t raffic st at efully. Also, Snort t riggers on t he first rule t hat a packet m at ches and does not exam ine t he rem aining rules. The order t hat rules are list ed in t he rules files is im port ant , but Snort does som e ordering of it s own. By default , Snort orders all rules by t heir act ion value in t he following order: alert , pass, and log. This can be overridden by a com m and- line opt ion t hat will be discussed lat er in t he sect ion, " The Act ion Field." However, Snort does som e furt her ordering by grouping ident ical headers t hat is beyond t he scope of t his chapt er. For m ore inform at ion, see www.snort .org/ docs/ faq.ht m l# 3.13. Look at Figure 13.1 t o see a sam ple Snort rule. Figu r e 1 3 .1 . Th e a n a t om y of a Snor t r u le .

You see a rule header t hat gives t he det ails of t he act ion t o be t aken if t he rule t riggers and t he inform at ion pert aining t o t he who values in t he packet . I n t his rule, we alert when TCP t raffic is observed t hat originat es from a net work t hat is not 10.1.1.x from any source port dest ined for net work 10.1.1.x t o any dest inat ion port . We assum e t hat our int ernal net work is t he 10.1.1.x net work, so t his rule t riggers when an out sider at t em pt s t o m ake an int ernal TCP connect ion. I f you t urn your at t ent ion t o t he rule opt ions, we furt her specify t he what of t he packet at t ribut es. I n t his inst ance, t he anom alous TCP flag pair of SYN and FI N is sought , and if found, a m essage of " SYN- FI N scan" is associat ed wit h t he alert . The rules keywords will be described m ore t horoughly in t he following sect ions. Rum or has it t hat t he rules synt ax will change radically when Snort version 2.0 m akes it s debut . So, if you are reading t his chapt er aft er t he release of Snort 2.0, it is best t o refer t o Snort docum ent at ion because t he inform at ion present ed here m ight be obsolet e. Ru le H e a de r Fie lds

As briefly m ent ioned, t he rule header is responsible for specifying t he act ion used t o respond t o a t riggered rule, as well as specifying t he prot ocol and source and dest inat ion addresses and port s. These who condit ions m ust be m et if t he rule opt ions are t o be exam ined. Rule opt ions will be explored in Chapt er 14. Th e Act ion Fie ld

The first field in t he rule header is t he act ion field. This field inst ruct s Snort on what t o do if t he rule is t riggered. The valid values for t he act ion field are t he following: z

z

z

z

z

Alert . This value inst ruct s Snort t o creat e an ent ry in t he alert file and t o log t he packet as well. The alert file is a single file t hat cont ains all det ect s t hat were m ade. The inform at ion writ t en t o t his file in t he default alert m ode consist s only of t he packet header inform at ion. For t he log ent ry, t he sam e inform at ion ( opt ionally including t he payload if t he - d com m and- line opt ion is specified) t hat is writ t en t o t he alert file is writ t en t o individual files found in a direct ory t hat usually has t he nam e of t he host ile I P num ber. Log. This value inst ruct s Snort t o only m ake a log ent ry. No record of t he t raffic is m ade in t he alert file when t he log act ion is used. The log files m ight have dat a from t he applicat ion payload if t he com m and- line opt ion t o decode t he applicat ion ( - d) is used. Pass. When a rule is t riggered t hat has pass specified as t he act ion, Snort does no furt her packet inspect ion—essent ially dropping t he packet from t he det ect ion engine. This is useful, for exam ple, if you want t o m onit or anonym ous ft p at t em pt s on your net work t o non- anonym ous ft p servers. You would writ e a pass rule t o ignore anonym ous ft p at t em pt s t o your valid anonym ous ft p server. You would t hen use a second, norm al, alert rule t o log all ot her anonym ous ft p at t em pt s. Act ivat e. These rules, when t riggered, not only alert , but are also used t o t urn on ot her rules ( dynam ic) t hat rem ain idle unt il t urned on. Dynam ic. These rem ain idle ( do not t rigger) unt il t urned on by an act ivat e rule. Aft er t hey are t urned on, t heir behavior is t he sam e as log rules.

Not e t hat t he act ivat e and dynam ic act ions are being replaced by t he t ag opt ion, which is found in t he rule opt ions. The t ag opt ion allows dynam ic capt ure of packet s for a given am ount of t im e or a specified num ber of packet s aft er t he rule t riggers. I t 's also possible t o define your own act ion t ypes, which can be used t o rout e rule out put t o various dest inat ions. This sophist icat ed usage is not covered here, but can be explored at Snort 's web sit e ( www.snort .org) . As briefly m ent ioned, t he default order in which rules are processed is alert rules first , pass rules second, and log rules last . To change t his default behavior, you m ust specify t he - o com m and- line opt ion when running Snort , which changes t he order t he rules are processed. Using t he - o opt ion changes t he rule processing order t o pass rules first , alert rules second, and log rules last . This was done when Snort was developed for public use t o avoid having an errant pass rule accident ally disable every alert and log rule in t he syst em . The –o opt ion was developed as an expert m ode for people aft er t hey underst ood how t he rules syst em worked.

Th e Pr ot ocol Fie ld

The prot ocol field in t he rule header t ells Snort which prot ocol t o exam ine. Snort current ly support s four different t ypes of net work t raffic: TCP ( Transm ission Cont rol Prot ocol) , UDP ( User Dat agram Prot ocol) , I CMP ( I nt ernet Cont rol Message Prot ocol) , and I P ( I nt ernet Prot ocol) . Addit ional prot ocols m ay be added in t he fut ure such as ARP, RARP, GRE, OSPF, RI P, and I PX. Snort underst ands only I P version 4, t hough it will not e t hat it has seen an I P version 6 packet . And, Snort is not I PSec aware, so it cannot decode unencrypt ed fields of t hose packet s. Th e Sou r ce a n d D e st in a t ion I P Addr e ss Fie lds

The source and dest inat ion I P address fields ident ify where t he host ile t raffic is com ing from and where it is going. I t is possible t o specify t he I P addresses as a host , a subnet , or m ult iple host s or subnet s. The I P addresses are specified in classless int er- dom ain rout ing ( CI DR) not at ion, an easy t o writ e and underst and form at . This form at includes as m uch of t he address as needed, along wit h t he num ber of bit s in t he net work m ask. Let 's exam ine t he form at and som e exam ples of I P addresses. Form at :

Address/netmask or any or [address/netmask,address/netmask…] Address = x.x.x.x Netmask = bits of network mask 24.0.0.0/8 = Class A 135.1.0.0/16 = Class B 192.168.5.0/24 = Class C 192.168.5.5/32 = Host address

Special keywords:

any - match all addresses ! negate address $HOME_NET – variable defined elsewhere in rules file

CI DR not at ion det ails t he base address and t he num ber of bit s of t he base address t hat are associat ed wit h t he net work. For inst ance, t he represent at ion 24.0.0.0/ 8 m eans t hat t his is a Class A address t hat has t he first oct et ( 24) allocat ed t o t he net work and all t he rem aining oct et s associat ed wit h host s on t he net work. Alt hough t he st andard Class A, B, and C CI DR not at ions are seen in t he previous exam ples, t he beaut y of CI DR not at ion is t hat t he net work bit s don't have t o fall on byt e boundaries, so t hey m ight represent all net work m asks.

You can specify an I P address list by enclosing all I P addresses or net works bet ween bracket s ( [ ] ) and delim it ing each of t he list values by com m as ( but no spaces in bet ween—t he Snort rule parser doesn't allow spaces in t he com m a delim it ed list ) . I f you want t o exam ine t raffic t o dest inat ion host 1.2.3.4 or subnet 2.3.4.x, t he following I P address list could be used:

[1.2.3.4,2.3.4.0/24]

A special keyword any can be used when any I P address is t he m at ching crit eria. And, as you've seen, t he exclam at ion point ( ! ) can be used t o negat e t he I P address value when all I P addresses but t he specified one are t o be considered. Finally, t o add m ore flexibilit y and port abilit y t o t he rules, a variable can be used t o indicat e t he I P address. The $HOME_NET variable is one t hat is used in m any of t he rules included wit h Snort t o indicat e t he user's/ analyst 's hom e net work. You can assign your int ernal net work any variable nam e you want , but because m any of t he rules already reference $HOME_NET, it is best t o use it . This variable m ust be defined in a rules file, t he configurat ion file, or on t he com m and line ( - S) before it is referenced.Variables can be used in ot her fields in t he rules as well. Th e Sou r ce a n d D e st in a t ion Por t Fie ld

The port fields are used t o det ail t he source and dest inat ion port s of t he t raffic. The port s can be list ed as a specific num ber, range of num bers, or t he keyword any, which represent s all possible source port s. Here are som e possible port represent at ions:

st at ic port :

111

all port s:

any

range:

33000: 34000

negat ion:

! 80

less t han or equal:

: 1023

great er t han or equal:

1024:

The first and m ost com m on port value is a st at ic one, such as port 111, t o represent t he port associat ed wit h t he Rem ot e Procedure Call ( RPC) port m apper. As wit h I P addresses, a generic port value can be supplied using t he keyword any. A range of port num bers can be specified, such as port s 33000 t hrough 34000 inclusive ( 33000: 34000) , which m ight represent UNI X t racerout e UDP port s. Negat ion is also support ed wit h port s as we are looking for any port but port 80 ( ! 80) above. Port s can be indicat ed as a less t han or equal t o condit ion or a great er t han or equal t o condit ion. The " : 1023" ident ifies t hat we want t o look for all port s

less t han or equal t o 1023 or t he reserved port range. Finally, t he " 1024: " is used t o say t hat all port s great er t han or equal t o 1024 should be considered—t he port s t ypically found in t he ephem eral source port range. You could also specify a port as a variable so long as you assigned a value t o t he variable before referencing it . You m ight be wondering if you have t o indicat e a port for t he I CMP prot ocol because it does not use port s like TCP and UDP. The rule synt ax requires port s, so you m ust specify som e kind of placeholder value. Alt hough no port value m akes sense, t he value " any" is oft en used. Let 's look at som e possible port values. D ir e ct ion I n dica t or

The t raffic direct ion field allows you t o indicat e t he direct ion t he packet m ust be t raveling. Two opt ions are available, allowing you t o indicat e a specific direct ion of flow, or t hat direct ion doesn't m at t er. Using t he not at ion t hat looks like an arrow ( - > ) , t he packet m ust be t raveling from a source t o a dest inat ion. The source inform at ion is specified t o t he left of t he arrow, and t he dest inat ion is t o t he right . The packet m ust be t raveling in t he list ed direct ion; if it is t raveling in t he opposit e direct ion, t he packet will not pass t he rule header t est and will not be inspect ed any furt her against t he rule. I f you use t he not at ion t hat looks sim ilar t o a double- headed arrow ( < > ) , t he packet can be t raveling t o or from eit her address/ port pair. For t his not at ion, eit her side can represent t he source or dest inat ion depending on t he packet flow in t he connect ion.

Su m m a r y Snort provides a very good NI DS at no cost for t he soft ware. Underst and t hat alt hough it is free t o use, t here are cost s associat ed wit h t he hardware, as well as cost s associat ed wit h cust om izing rules and m aking sense of t he out put . Snort is m ost useful when run in packet - sniffing m ode where it com pares t he net work t raffic against a set of rules. This can be done eit her in real- t im e m ode, or t raffic can be capt ured in binary form at and ret rospect ively analyzed lat er by feeding it back int o Snort as an input file. Snort rules provide a flexible and easily configurable m eans of specifying m ost header fields t o inspect , as well as analyzing any dat a in t he payload. The rules allow t he user m any different ways t o indicat e values for part icular fields in addit ion t o perm it t ing t he use of variables t o represent values. Snort rules also provide t he granularit y necessary t o be very explicit about t he at t ribut es of t he packet t hat are t o be inspect ed or ignored. The result is t hat t here should be far fewer false posit ives and false negat ives if t he rules are properly configured for t he sit e.

Ch a pt e r 1 4 . Sn or t Ru le s—Pa r t I I

The previous chapt er provided an int roduct ion t o Snort , in general, and Snort rules. As you will recall, a Snort rule is com posed of a rule header, which was exam ined in det ail in t he previous chapt er, and a rule opt ion, which will be covered t horoughly in t his chapt er. The rule header supplies t he act ion t hat will be applied if t he rule is t riggered. I t det ails t he source and dest inat ion I P addresses and port s, t he prot ocol, and t he direct ion of t he t raffic flow. The rule header can be used alone t o form a rule, but it is usually followed by a rule opt ion t o provide m ore det ail about t he packet at t ribut es. I ronically, t here are som e com m ercial NI DS t hat only allow t he sam e level of det ail as a Snort rule header when specifying a signat ure. I n ot her words, t hey don't allow t he user t o configure m uch m ore t han t he I P addresses, prot ocol, and TCP or UDP port s t o define a signat ure. Obviously, t his cannot be considered very robust in t erm s of rule or packet granularit y. The rule opt ions form t he core of Snort 's int rusion- det ect ion capabilit ies.

For m a t of Sn or t Opt ion s The rule opt ions are separat ed from t he rule header via required parent heses ( ) . Look at t he following rule:

alert tcp !$HOME_NET any -> $HOME_NET any (flags: SF; \ msg: "SYN-FIN scan";)

The opt ions port ion is as follows:

(flags: SF; msg: "SYN-FIN scan";)

Each opt ion is m ade up of an opt ion keyword, and possibly a value for t he part icular opt ion keyword. I n t he preceding exam ple, you find t he opt ion keyword flags paired wit h a value of SF and an opt ion keyword of m sg paired wit h a value of SYN- FI N scan. The value t hat is associat ed wit h a given opt ion keyword depends on t he opt ion. Som e opt ions require num eric values and ot hers require t ext . Opt ion keywords are separat ed from t he associat ed value via t he colon ( : ) , and individual opt ions are delim it ed by a sem i- colon ( ; ) . A sem i- colon m ust follow t he final opt ion as well or an error will be generat ed. Alt hough m ost opt ion keywords are usually followed by a value, t here are som e opt ions t hat require no value. One such exam ple is t he opt ion nocase t hat indicat es a search for cont ent in t he packet 's payload is t o be case insensit ive. Snort is pret t y unconcerned and forgiving about t he lack or abundance of whit espace bet ween delim it ers such as ; and : . You don't have t o supply spaces, or you can supply m ult iple spaces bet ween opt ions, values, and delim it ers. For inst ance, t he t wo following opt ions should bot h work:

(flags:SF;msg:"SYN-FIN scan";) (flags: SF ; msg : "SYN-FIN scan"

;)

The backslash ( \ ) is a rule cont inuat ion charact er; rules can be cont inued on separat e lines if t his charact er is supplied at t he end of any unfinished line. Speaking of special charact ers, t he pound sign ( # ) is used as t he com m ent charact er for Snort rules.

Ru le Opt ion s Som e of t he m ost im port ant and com m only used opt ions will be discussed now t o convince you of t he power of Snort rules. The ent ire list of burgeoning opt ions will not be covered, but descript ions of all of t hem can be found at ht t p: / / www.snort .org/ by exam ining t he online Snort Users Manual under t he docum ent at ion link. M sg Opt ion The m sg opt ion allows t he user or analyst t o assign an appropriat e m essage t o t he out put of a t riggered rule. When you exam ine an alert or logged ent ry for t he t riggered rule, you will see t he offending packet . You will not see t he act ual rule t hat t riggered t he alert in t he out put it self, so you need som e descript ive way of associat ing t he alert wit h t he rule. I f you assign an m sg opt ion value, it will appear before t he offending packet out put t o give you a bet t er idea of why t he rule t riggered. Look at t he following form at , rule, and an associat ed alert t hat t riggered from t he rule:

Form at :

msg: "";

Sam ple rule:

alert udp any any -> 192.168.5.0/24 31337 \ (msg:"Back Orifice";)

Sam ple out put :

[**] Back Orifice [**] 04/24-08:49:21.318567 192.168.143.15:60256 -> 192.168.5.16:31337 UDP TTL:41 TOS:0x0 ID:49951 Len: 8

The Snort rule says t o alert ( and log) when a UDP packet from any source I P address or port goes t o subnet 192.168.5 dest inat ion port 31337 and t o assign it a m essage of " Back Orifice" . When t he rule is t riggered, t he alert is recorded wit h " [ * * ] Back Orifice [ * * ] " t o describe t he act ivit y. Logt o Opt ion The logt o opt ion allows you t o specify a filenam e t o which t o log t he act ivit y. This applies t o rules wit h t he alert or log act ion in t he rule header only. A rule t hat is t riggered wit h t he alert or log act ion will norm ally writ e t o a default direct ory ( eit her / var/ log/ snort for UNI X host s or, on a Windows m achine, a subdirect ory nam ed log from wherever Snort is launched) or a direct ory specified using t he –l filenam e opt ion on t he com m and line. This assum es t hat t he user hasn't changed t he default logging t o binary out put ( - b com m and- line opt ion) , t o send t he out put t o t he syslog daem on ( - s com m and- line opt ion) , or disabled logging alt oget her ( - N com m and- line opt ion) . The logt o opt ion can be used t o send t he out put for a specific rule or class of userchosen rules t o a given file. Why m ight you want t o use t his opt ion? Well, t his is an excellent way t o separat e t he t ruly dangerous or harm ful kinds of alert s from t hose t hat are t he garden variet y. I n t he case shown in t he exam ple, if you suspect t hat you have som e kind of t rinoo dist ribut ed denial- of- service ( DDoS) infest at ion or any ot her DDoS act ivit y on t he net work, you can look direct ly at t he DDoS file for signs of t his. This will also be logged t o t he default alert file as well because t he following sam ple rule uses t he act ion alert . Form at :

logto: "";

The supplied filenam e should not include a pat h, only a filenam e. I ncluding a pat h causes Snort t o display an error m essage. You should place t he filenam e in quot es, ot herwise an init ial space is som et im es added before t he nam e. Sam ple rule:

alert udp any any -> 192.168.5.0/24 31335 \ (msg: "trinoo port"; logto: "DDoS";)

Sam ple out put : I f t he rule is t riggered, t he out put on t his UNI X host will be found in / var/ log/ snort / DDoS:

[**] trinoo port [**] 04/24-09:07:41.320938 192.168.143.15:56881 -> 192.168.5.16:31335 UDP TTL:42 TOS:0x0 ID:4011 Len: 8

Tt l Opt ion The t t l opt ion allows you t o exam ine t he arriving t im e- t o- live field for a specific value. This opt ion could be used for a variet y of reasons. One reason t o exam ine t his field would be t o look for a packet wit h a low arriving TTL value, which can be indicat ive of a UNI X host perform ing a t racerout e or a Windows host perform ing a t racert . When t he prot ocol is UDP and t he port ranges are 33000 t hrough 34000, it is m ost likely a UNI X t racerout e. A Windows t racert is done via I CMP echo request s. The following rule looks for UNI X t racerout e t raffic t o t he 192.168.5 net work wit h a UDP port in t he range 33000 t hrough 34000 inclusive and an arriving TTL value of 1. Form at :

ttl: ;

Sam ple rule:

alert udp any any -> 192.168.5.0/24 33000:34000 \ (msg: "Unix traceroute"; ttl: 1;)

Sam ple out put :

[**] Unix traceroute [**] 04/24-09:29:37.971353 192.168.143.15:40920 -> 192.168.5.16:33437 UDP TTL:1 TOS:0x0 ID:40923 Len: 18

I d Opt ion As you recall, t he I P ident ificat ion value is a 16- bit value t hat is found in t he I P header of each dat agram . Each new dat agram is assigned a unique I P I D num ber t hat is t ypically increm ent ed by 1 for each packet . This num ber becom es t he fragm ent I D, which assist s t he dest inat ion host in reassem bling fragm ent s. The sam ple rule looks for an unusual I P I D value of 0. I t now appears t hat Linux 2.4 kernels set t he I P I D value t o 0 when t he Don't Fragm ent ( DF) flag is set in t he packet . The reasoning for t his is t hat if t he packet will never becom e fragm ent ed, why bot her t o assign it a fragm ent I D? Form at :

id: ;

Sam ple rule:

alert icmp any any -> 192.168.5.0/24 any \ (msg: "Suspect IP Identification #"; ID:0;)

Sam ple out put :

[**] Suspect IP Identification # [**] 04/25-09:21:36.371005 192.168.143.15 -> 192.168.5.16 ICMP TTL:64 TOS:0x0 ID:00

D size Opt ion The dsize opt ion allows Snort t o exam ine t he size of t he payload. You can inspect t he payload size for an exact value, or a value less t han or great er t han a part icular num ber. This can com e in handy when you are creat ing a rule for buffer overflow at t acks. These at t acks m ight have a t ellt ale signat ure of having a larger

payload t han expect ed. The following sam ple rule looks for I CMP packet s wit h a payload size great er t han 1,024 byt es. Form at :

dsize: [] number

Sam ple rule:

alert icmp any any -> 192.168.5.0/24 any \ (msg: "Large ICMP payload"; dsize: >1024;)

Sam ple out put :

[**] Large ICMP payload [**] 04/24-11:10:24.110169 192.168.143.100 -> 192.168.5.16 ICMP TTL:255 TOS:0x0 ID:5487 DF ID:7564 Seq:0 ECHO

Se qu e n ce Opt ion The sequence opt ion checks t he value of t he TCP sequence num ber. The Shaft dist ribut ed denial- of- service soft ware is known t o assign a fixed sequence num ber—hexadecim al 28374839—when a TCP flood is direct ed t o a vict im sit e. No doubt , t his is som et hing t hat is configurable in t he source code, so t his is not a failsafe m et hod of ident ifying Shaft . Of course, a benign packet could coincident ally be using t he sam e sequence num ber, t oo. Form at :

seq: ;

Sam ple rule:

alert tcp any any -> any any \ (msg: "Possible Shaft DDoS"; seq: 0x28374839;)

Sam ple out put :

[**]Possible Shaft DDoS [**] 04/25-07:19:58.582562 192.168.143.100:35680 -> 192.168.143.15:23 TCP TTL:255 TOS:0x0 ID:7705 DF ******S* Seq: 0x28374839 Ack: 0x0 Win: 0x2238 TCP Options => MSS: 1460

Ack n ow le dge m e n t Opt ion The acknowledgem ent opt ion exam ines t he value of a TCP acknowledgem ent num ber. The prim ary use for t his current ly is t o det ect nm ap pings. As you discovered in t he previous chapt er, nm ap sends a unique signat ure when it t ries t o assess if a host is alive. I t set s t he ACK flag on, and it set s t he acknowledgem ent value of 0. This would be a rare set t ing t o find in norm al t raffic because it would be indicat ive of an already est ablished connect ion acknowledging t hat t he previous TCP sequence num ber received was 2 32 – 1, and now t he acknowledgem ent num ber is wrapping back t o 0. Form at :

ack: ;

Sam ple rule:

alert tcp any any -> any any \ (msg: "nmap TCP ping"; flags: A; ack: 0;)

Sam ple out put :

[**] nmap TCP ping [**] 04/25-07:27:13.578488 192.168.143.15:63367 -> 192.168.143.16:80 TCP TTL:42 TOS:0x0 ID:26253 ***A**** Seq: 0x16680003 Ack: 0x0 Win: 0xC00

I t ype a n d I code Opt ion s The it ype opt ion is used t o select a part icular I CMP m essage t ype. The m essage t ype field is found in t he zero byt e offset of t he I CMP m essage.Valid values for t his and it s part ner opt ion icode, which is used t o represent t he I CMP m essage code, can be found at www.iana.org/ assignm ent s/ icm p- param et ers. The icode opt ion is oft en used in conj unct ion wit h t he it ype opt ion. The I CMP m essage code is found in t he first byt e offset of t he I CMP m essage. Many I CMP m essages share t he sam e t ype but are furt her delineat ed using t he I CMP code field. For inst ance, an I CMP t ype of 3 has m any different I CMP codes associat ed wit h it . I f you are j ust int erest ed in seeing I CMP port unreachable m essages, you m ust qualify t he rule

wit h an it ype value of 3 and an icode value of 3. Form at :

itype: ; icode: ;

Sam ple rule:

alert icmp 1.1.1.0/24 any -> 192.168.5.0/24 any \ (msg: "port unreachable"; itype: 3; icode: 3;)

Sam ple out put :

[**] port unreachable [**] 04/25-07:56:37.129338 1.1.1.16 -> 192.168.5.15 ICMP TTL:255 TOS:0xC0 ID:33569 DESTINATION UNREACHABLE: PORT UNREACHABLE

Fla gs Opt ion The flags opt ion enables you t o inspect TCP flag set t ings in m any different ways. St art ing from t he least significant ( right m ost ) flag bit set t ing:

F:

Finish flag set

S:

Synchronize flag set

R:

Reset flag set

P:

Push flag set

A:

Acknowledgem ent flag set

U:

Urgent flag set

2:

ECN echo flag set ( form erly a reserved bit )

1:

ECN congest ion window reduced set ( form erly a reserved bit )

0:

No flag bit s set

I t 's also possible t o use one of t hree m odifiers ( + ,* ,! ) t o assist in exam ining flag com binat ions or negat ing a flag set t ing. For inst ance, t he A+ flag set t ing indicat es t hat t he Acknowledgem ent flag m ust be set . I t can be set alone, or any ot her flag m ight be set along wit h it . This could include an acknowledgem ent on push flag

( m eaning new dat a is being sent at t he sam e t im e received dat a is being acknowledged t o com bine t r ansfers int o one packet ) , which is a com m on and legit im at e com binat ion. The * m odifier is used when you have a com binat ion of flags and any of t hose flags m ight be set . For inst ance, SFP* says t hat any com binat ion of t he SYN, FI N, and PSH flags can be set —t hey can all be set ; a lone SYN, FI N, or PSH can be set ; or any pair in t he t rio can be set . Finally, t he ! m odifier specifies t o negat e t he current flag set t ing. The flags opt ion ! S specifies t hat any TCP segm ent wit hout t he SYN flag set will be a candidat e packet . Form at :

flags:

Flag Set t ings: F = FI N

S = SYN

R = RST

P = PSH

A = ACK

U = URG

2 = ECE

1 = CWR

0 = No flags set

See Figure 14.1 for a pict orial represent at ion of Snort 's TCP flag bit s. Possible flag m odifiers: Figu r e 1 4 .1 . Sn or t 's vie w of t h e TCP fla g byt e .

+

All, m at ch if list ed flag( s) set and any ot hers set

*

Any, m at ch if any com binat ion of list ed flag( s) set

!

Not , m at ch if list ed flag( s) NOT set

Sam ple rule:

alert tcp

any any -> any any (msg:"Null Scan"; flags:0;)

Sam ple out put :

[**] Null Scan [**] 04/25-05:49:51.914748 192.168.143.15:54746 -> 192.168.143.16:21 TCP TTL:51 TOS:0x0 ID:23446 ******** Seq: 0x1CED3E2E Ack: 0x0 Win: 0x1000 TCP Options => WS: 10 NOP MSS: 265 TS: 1061109567 0 EOL EOL

I n t he previous sam ple out put , you see a st ring of eight ast erisks ( * * * * * * * * ) . Snort changes an ast erisk t o it s respect ive flag bit let t er associat ion ( 12UAPRSF) if t he flag is set in t he packet t hat t riggered t he alert . Because t his is a null scan, no flag bit s are set ; hence, you see all ast erisks. Con t e n t Opt ion The cont ent opt ion is one of t he m ost vit al and pot ent ially m isused opt ions. I t provides a m eans of supplying payload cont ent t o search for in t he packet . There are m any ways t o supply t he cont ent value and m ult iple different cont ent values can be sought . This opt ion is used liberally t hroughout t he rules t hat are supplied

in t he Snort download, but t he cont ent opt ion should also be used wisely. Seeking cont ent in payload is considered t o be com put at ionally expensive—in ot her words, t his can slow Snort down considerably if it is not done int elligent ly. Alt hough t he developers of Snort have m axim ized t he efficiency of t he algorit hm applied t o do cont ent searches, it is a slow operat ion when com pared wit h a m ore exact t ask such as a m at ch of a header field value. This is because t he header field value is, at m ost , four byt es long, yet payloads are oft en m uch longer, t hus t aking m ore t im e t o search. I f at all possible, t he cont ent opt ion should be qualified wit h ot her opt ions as flags or t hose t hat will be discussed short ly, such as an offset int o t he payload where t he cont ent search begins, and dept h int o t he payload where t he cont ent search ends. The cont ent opt ion is t est ed last even if it is list ed first in t he rule opt ions. This is done t o opt im ize t he search by qualifying it wit h ot her opt ions. Cont ent st rings can be represent ed as t ext or a hexadecim al t ranslat ion of binary dat a or a com binat ion of t ext and hexadecim al. Text st rings are enclosed in quot es ( " " ) and m at ches are case sensit ive unless t he nocase opt ion is used. Hexadecim al code is delim it ed wit h t he pipe ( | ) charact ers. Mult iple cont ent opt ions and values can be specified in a rule and all values associat ed wit h t he m ult iple cont ent opt ions m ust be found in t he packet . The cont ent values associat ed wit h t he m ult iple cont ent opt ions can appear in any order in t he payload; in ot her words, t hey do not have t o m at ch t he order in which t hey are list ed in t he rule. There is anot her available cont ent opt ion t hat will not be covered known as t he cont ent list . This allows m ult iple cont ent st rings t o be specified and if any of t hem m at ch, t he rule t riggers. The Snort Users Manual found on ht t p: / / www.snort .org/ discusses t his opt ion and gives an exam ple. Form at :

content: ; content: ; content: ;

Sam ple rule:

alert udp $EXTERNAL_NET any -> $HOME_NET 53 \ (msg: "EXPLOIT BIND tsig Overflow Attempt"; \ content: "|00 FA 00 FF|"; content: "/bin/sh";);

Sam ple out put :

02/22-15:33:19.472301 ATTACKER:1024 -> VICTIM:53 UDP TTL:64 TOS:0x0 ID:6755 IpLen:20 DgmLen:538

Len: 518

00 0E 1E 2E 07 08 18 28 38 02 D8 22 32 00 0C 1C 2C 3C

3F 0F 1F 2F C0 09 19 29 39 03 FA 23 33 00 0D 1D 2D EB

90 10 20 30 00 0A 1A 2A 3A 04 FF 24 34 00 0E 1E 2E 07

E8 11 21 31 00 0B 1B 2B 3B 05 BF 25 35 3F 0F 1F 2F C0

72 12 22 32 00 0C 1C 2C 3C 06 D8 26 36 00 10 20 30 00

FF 13 23 33 00 0D 1D 2D EB 07 F7 27 37 01 11 21 31 00

FF 14 24 34 00 0E 1E 2E 07 08 FF 28 38 02 12 22 32 00

FF 15 25 35 3F 0F 1F 2F C0 09 BF 29 39 03 13 23 33 00

2F 16 26 36 00 10 20 30 00 0A D0 2A 3A 04 14 24 34 00

62 17 27 37 01 11 21 31 00 0B 7C 2B 3B 05 15 25 35 00

69 18 28 38 02 12 22 32 00 0C 0D 2C 3C 06 16 26 36 00

6E 19 29 39 03 13 23 33 00 0D 08 2D EB 07 17 27 37 FA

2F 1A 2A 3A 04 14 24 34 00 0E 04 2E 07 08 18 28 38 00

73 1B 2B 3B 05 15 25 35 3F 0F F7 2F C0 09 19 29 39 FF

68 00 .?..r.../bin/sh. 1C 1D ................ 2C 2D .. !"#$%&'()*+,3C EB ./0123456789:; $HOME_NET 5632 \ (msg: "PCAnywhere Startup"; content: "ST"; depth: 2;)

Sam ple out put :

[**] PCAnywhere Startup [**] 04/24-12:11:08.724441 192.168.143.15:3484 -> 192.168.143.16:5632 UDP TTL:64 TOS:0x10 ID:30124 DF 73 74 61 72 74 75 70 STARTUP

This rule is t riggered if t he charact ers " ST" are discovered t wo byt es from t he

default offset of byt e 0. N oca se Opt ion

The nocase opt ion m akes t he cont ent search in t he payload case insensit ive. This m eans t hat Snort will m at ch t he cont ent st ring being searched no m at t er what case is used. This is one of t he few opt ions t hat does not have an opt ion value part nered wit h it . Form at :

nocase;

Sam ple rule:

alert tcp any any -> any 21 \ (msg: "FTP warez snooping"; content: "warez"; nocase;)

Sam ple out put :

[**] FTP warez snooping[**] 04/25-05:28:28.146374 192.168.143.15:3487 -> 192.168.143.16:21 TCP TTL:64 TOS:0x10 ID:30637 DF ***AP*** Seq: 0xE1977C8D Ack: 0x452F7F9 Win: 0x7D78 TCP Options => NOP NOP TS: 118248207 33775174 43 57 44 20 57 61 52 65 5A 0D 0A CWD WaReZ.. Re ge x Opt ion

The regex opt ion m odifier of cont ent allows wildcard charact ers t o appear in t he cont ent st ring. Two wildcard charact ers are available: t he ? specifies t hat a single charact er can be subst it ut ed in t he posit ion where t he ? is found. The second wildcard charact er * indicat es t hat any num ber of charact ers can be subst it ut ed where t he * is found. One excellent use of t he regex opt ion is looking for signs of buffer overflow charact ers. I f a buffer overflow is successful on a UNI X host , t he at t acker m ight very well t ry t o gain access t o a shell such as t he Bourne shell using / bin/ sh. Yet , t here are m any ot her shells t hat can be used such as t he C shell ( csh) , t he Korn shell ( ksh) , and Bourne again shell ( bash) , t o nam e a few. Therefore, specifying a proper st ring and wildcard charact er will find all of t he various shells. Prior t o t he addit ion of t he regex opt ion, t he only way t o t est for all different shells was t o use different rules. Be warned t hat t he regex opt ion will not be fully funct ional unt il release 2.0 of Snort .

Form at :

regex;

Sam ple rule:

log tcp any any -> 192.168.5.0/24 515/ (msg: "Attempted shell on lpd"; content: "/bin/*sh"; regex;)

Sam ple out put :

[**] Attempted shell on lpd [**] 03/23-07:41:11.282960 1.1.0.1:1892 -> 192.168.5.55:515 TCP TTL:64 TOS:0x0 ID:63821 IpLen:20 DgmLen:60 ***AP*** Seq: 0x32A77D55 Ack: 0x0 Win: 0x200 TcpLen: 20 2F 62 69 6E 2F 63 73 68 0A 00 00 00 00 00 00 00 /bin/csh........ 00 00 00 00

The previous rule looks for shell access t o dest inat ion port 515 known as t he line print er daem on. The regex qualifier t o t he cont ent value of / bin/ * sh is used t o find all t he different t ypes of shell access. Se ssion Opt ion The session opt ion is used t o capt ure user dat a from TCP sessions. I t can provide a good forensics t ool t o see what a part icular user is doing, especially if you suspect som e kind of m alicious behavior is t aking place. There are t wo available argum ent keywords for t he session rule opt ion: print able or all. The print able keyword only print s out dat a t hat t he user would norm ally see or be able t o t ype. The all keyword subst it ut es non- print able charact ers wit h t heir hexadecim al equivalent s. You should be aware t hat t he use of t he session opt ion can degrade t he perform ance of Snort , so it is best used ret rospect ively; capt ure t he dat a in binary form at ( TCPdum p files) and t hen run it t hrough Snort . Also, not e t hat t ypically when you use t his opt ion, you should use t he direct ion operat or t hat specifies bot h direct ions as shown in t he exam ple. Finally, it is best t o use t he –d com m and- line opt ion t o dum p at t he applicat ion level; ot herwise, it doesn't m ake m uch sense t o specify t he session opt ion. By default , t he session is recorded in t he default log direct ory. The subdirect ory beneat h t hat is t he I P num ber of t he host init iat ing t he act ivit y. A file nam ed

SESSI ON: sourceport - dest port , where sourceport and dest port are t he act ual source, dest inat ion port s for t he connect ion will be locat ed in t hat direct ory. Form at :

session: [printable|all]

Sam ple rule:

log tcp any any 192.168.5.0/24 21 (session: printable;)

Sam ple out put : Assum ing t he source host for t he session is 1.2.3.4 on port 1025, t he following out put will be in t he log direct ory in subdirect ory 1.2.3.4 file SESSI ON: 1025- 21:

220 linux2 FTP server (Version wu-2.5.0(1) Tue Sep 21 16:48:12 EDT 1999) ready. USER jsmith 331 Password required for jsmith. PASS snorty-the-p1g 230 User jsmith logged in. SYST 215 UNIX Type: L8 QUIT 221-You have transferred 0 bytes in 0 files. 221-Total traffic for this session was 239 bytes in 0 transfers. 221-Thank you for using the FTP service on linux2. 221 Goodbye

Re sp Opt ion The resp opt ion allows an aut om at ed act ive response when m alicious act ivit y is det ect ed. An act ive response at t em pt s t o disable a connect ion. There are m any different com binat ions of act ive responses and m ult iple resp opt ions can be given in a single rule. TCP connect ions can be abort ed by sending a reset t o t he sending host socket connect ion, t he receiving host socket connect ion, or bot h host s' socket connect ions. I f t he offending packet is UDP, different I CMP m essages can be sent in an at t em pt t o int errupt t he UDP dat a flow. An I CMP net work, host , or port unreachable m essage—or a com binat ion of all t hree of t hese I CMP m essages—can be sent . The response opt ion doesn't com e aut om at ically enabled wit h t he source

dist ribut ion. To enable it , you m ust explicit ly configure Snort via t he following com m and:

./configure

--enable-flexresp

This includes t he necessary code for com pilat ion. I t is also possible t hat your configurat ion of UNI X doesn't have a libnet .h include file required for t his t o com pile. I t is available from ht t p: / / www.packet fact ory.net / . No discussion of act ive response is com plet e unless t he requisit e caveat s are offered. First , t hink sm oking- brain hard before you decide t o indiscrim inat ely use act ive response. I t should be used for sit uat ions where you perceive t hat unaut horized harm ful access could occur such as a buffer overflow. Keep in m ind t hat at t ackers can spoof source I P addresses, and you m ight end up using act ive response against an I P address or addresses t hat never sent you t raffic t o begin wit h. Think about t he consequences of act ive response if som eone spoofs a legit im at e part ner's I P addresses; it is possible for you t o end up at t acking a vit al resource. Also, a false posit ive could cause a t ot ally benign connect ion t o be halt ed. This can cause a denial of service t o legit im at e users. Anot her concern is t im ing issues. Many request s and responses are alm ost inst ant aneous, especially one such as a UDP DNS query- response pair. At t em pt ing t o act ively respond t o a perceived m alicious DNS query m ight prove t o be fut ile because by t he t im e Snort react s, t he response has probably already been sent . Form at :

resp ;

Available choices for t he response are:

rst _snd

Send TCP RESET packet s t o sending socket

rst _rcv

Send TCP RESET packet s t o receiving socket

rst _all

Send TCP RESET packet s t o bot h sending and receiving socket s

icm p_net

Send an I CMP_NET_UNREACH t o sender

icm p_host

Send an I CMP_HOST_UNREACH t o sender

icm p_port

Send an I CMP_PORT_UNREACH t o sender

icm p_all

Send all of t he above I CMP_UNREACH packet s t o sender

Sam ple rule:

alert tcp any any -> $HOME_NET 21 \ (msg: "FTP password file retrieval"; \ flags: A+; resp: rst_all; content: "passwd";)

Sam ple session:

[root@verbo hping2-beta53]# ftp sparky Connected to sparky. 220 sparky FTP server (SunOS 5.7) ready. Name (sparky:root): jsmith 331 Password required for jsmith. Password: 230 User jsmith logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /etc 250 CWD command successful. ftp> get passwd local: passwd remote: passwd 200 PORT command successful. 421 Service not available, remote server has closed connection

The previous rule calls for an act ive response t o a connect ion t o an ft p server t hat references t he password file passwd. Snort reset s bot h ends of t he connect ion t o int errupt t his at t em pt because t he resp opt ion of rst _all was select ed. Look at t he last line of t he ft p session. You see t hat right aft er t he at t acker ent ered t he com m and get passwd, t he connect ion was act ually closed. I t is possible t hat t he password file had already been t ransferred before t he reset occurred. Ta g Opt ion The use of t he t ag opt ion enables Snort t o dynam ically capt ure addit ional packet s aft er a rule t riggers. Wit hout t he t ag opt ion, only t he packet t hat caused t he rule t o be t riggered is recorded. This is an excellent way t o see what t ranspires aft er t he rule is t riggered t o get a bet t er idea of t he int ent of t he act ivit y. This can also be useful for validat ing t hat som e act ivit y t hat t riggered a rule is sim ply a false posit ive. Form at :

tag: , , , [direction]

z

t ype. What t raffic t o record. { {

session. Record t he packet s from bot h sides of t he connect ion host . Record t he packet s from t he host t hat caused t he rule t o t rigger ( m ust use direct ion m odifier)

z

count . Num ber of unit s specified by m et ric.

z

m et ric. Num ber of packet s/ seconds t o record.

z

{

packet s. Record host / session for < count > packet s.

{

seconds. Record host / session for < count > seconds.

direct ion. Used only wit h " host " t ype t o indicat e host t o t ag. {

src. Tag all t raffic of source I P in t riggered rule.

{

dst . Tag all t raffic of dest inat ion I P in t riggered rule.

Sam ple rule:

alert tcp any any -> any 21 (msg: "FTP passwd access"; flags: A+; \ content: "passwd"; tag: session, 10, packets;)

Sam ple out put : The alert file shows t he abbreviat ed dat a from t he m iscreant connect ion t o dest inat ion port 21:

[**] FTP passwd access [**] 03/21-20:31:05.610035 10.10.10.101:1454 -> 10.10.10.100:21 TCP TTL:128 TOS:0x0 ID:50697 IpLen:20 DgmLen:58 DF ***AP*** Seq: 0x17806739 Ack: 0x121C07E5 Win: 0x1FD3 TcpLen: 20

A direct ory nam ed 10.10.10.101 was creat ed wit h a file nam ed TCP: 1454- 21 t o record t he session exchange of t he at t em pt ed password file access and 10 subsequent records. Not e t hat t he com m and line used t he –d opt ion t o capt ure and dum p t he dat a payload. This is an excerpt of t he out put :

03/21-20:31:05.610035 10.10.10.101:1454 -> 10.10.10.100:21 TCP TTL:128 TOS:0x0 ID:50697 IpLen:20 DgmLen:58 DF ***AP*** Seq: 0x17806739 Ack: 0x121C07E5 Win: 0x1FD3 TcpLen: 20

52 45 54 52 20 2F 65 74 63 2F 70 61 73 73 77 64 0D 0A

RETR /etc/passwd ..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 03/21-20:31:05.610731 10.10.10.100:21 -> 10.10.10.101:1454 TCP TTL:64 TOS:0x10 ID:1752 IpLen:20 DgmLen:109 DF ***AP*** Seq: 0x121C07E5 Ack: 0x1780674B Win: 0x7D78 TcpLen: 20 31 35 30 20 4F 70 65 6E 69 6E 67 20 41 53 43 49 150 Opening ASCI 49 20 6D 6F 64 65 20 64 61 74 61 20 63 6F 6E 6E I mode data conn 65 63 74 69 6F 6E 20 66 6F 72 20 2F 65 74 63 2F ection for /etc/ 70 61 73 73 77 64 20 28 36 37 39 20 62 79 74 65 passwd (679 byte 73 29 2E 0D 0A s)... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 03/21-20:31:08.924038 10.10.10.101:1454 -> 10.10.10.100:21 TCP TTL:128 TOS:0x0 ID:52489 IpLen:20 DgmLen:58 DF ***AP*** Seq: 0x17806764 Ack: 0x121C0860 Win: 0x1F58 TcpLen: 20 52 45 54 52 20 2F 65 74 63 2F 73 68 61 64 6F 77 RETR /etc/shadow 0D 0A ..

Pu t t in g I t All Toge t h e r Now t hat you've endured t he t edium t o underst and Snort rules, you m ight be wondering how you would writ e a rule for a new exploit t hat was released. Chances are t hat t he user/ developer populat ion of Snort will have a new rule out for a current exploit very quickly. But , assum e you have som e code t hat professes t o be an at t ack for which no Snort rule exist s. The first t hing t o do is t o execut e t he exploit code in an isolat ed t est net work such as your hom e or a segregat ed lab environm ent at work. I f t he code works as advert ised, record t he packet exchange bet ween t he at t acking and vict im host s. Then, look for unique and repeat able values in t he packet t hat can be used t o writ e a signat ure or rule. You m ight have t o read som e RFCs t o becom e acquaint ed wit h t he prot ocol used in t he exploit t o underst and which are repeat able and which are m odifiable values. Suppose you downloaded som e code t hat exploit ed a buffer overflow condit ion for DNS TSI G ( t ransact ion signat ure) records. This is an act ual at t ack t hat was effect ive against unpat ched versions of BI ND from 4.x up t o, but not including, 8.2.3. A TSI G record in DNS is anot her resource record t ype like an address or point er record. I t is used by resolvers and for dynam ic updat es t o ensure t he int egrit y of an exchanged DNS record using a crypt ographic one- way hash and shared secret key. Because t he exploit at t em pt s t o get access t o a shell at t he privilege level t hat BI ND ( t he " nam ed" daem on) runs at , t he capt ured t raffic from t he exploit should

be exam ined for t his signat ure. Here is t he packet t hat cont ains t he buffer overflow and subsequent at t em pt t o get shell access:

02/22-15:33:19.472301 ATTACKER:1024 -> VICTIM:53 UDP TTL:64 TOS:0x0 ID:6755 IpLen:20 DgmLen:538 Len: 518 DE 03 13 23 33 00 40 80 C2 8D B0 89 B0 87 00 0E 1E 2E 07 08 18 28 38 02 D8 22 32 00 0C 1C 2C 3C

AD 04 14 24 34 00 89 43 89 4E 66 56 3F F3 3F 0F 1F 2F C0 09 19 29 39 03 FA 23 33 00 0D 1D 2D EB

01 05 15 25 35 00 C3 C6 46 08 CD 10 41 8D 90 10 20 30 00 0A 1A 2A 3A 04 FF 24 34 00 0E 1E 2E 07

80 06 16 26 36 00 89 46 18 EB 80 B0 CD 4B E8 11 21 31 00 0B 1B 2B 3B 05 BF 25 35 3F 0F 1F 2F C0

00 07 17 27 37 00 46 10 B0 07 89 66 80 0C 72 12 22 32 00 0C 1C 2C 3C 06 D8 26 36 00 10 20 30 00

07 08 18 28 38 3F 0C 10 90 C0 5E 43 B0 B0 FF 13 23 33 00 0D 1D 2D EB 07 F7 27 37 01 11 21 31 00

00 09 19 29 39 00 40 66 66 00 0C CD 3F 0B FF 14 24 34 00 0E 1E 2E 07 08 FF 28 38 02 12 22 32 00

00 0A 1A 2A 3A 01 89 89 89 00 43 80 41 CD FF 15 25 35 3F 0F 1F 2F C0 09 BF 29 39 03 13 23 33 00

00 0B 1B 2B 3B EB 46 5E 46 00 43 86 CD 80 2F 16 26 36 00 10 20 30 00 0A D0 2A 3A 04 14 24 34 00

00 0C 1C 2C 3C 44 08 14 16 00 B0 C3 80 EB 62 17 27 37 01 11 21 31 00 0B 7C 2B 3B 05 15 25 35 00

00 0D 1D 2D EB 5E 8D 88 8D 00 66 B0 88 07 69 18 28 38 02 12 22 32 00 0C 0D 2C 3C 06 16 26 36 00

01 0E 1E 2E 0A 29 4E 46 4E 3F CD 3F 56 C0 6E 19 29 39 03 13 23 33 00 0D 08 2D EB 07 17 27 37 FA

3F 0F 1F 2F 02 C0 08 08 14 EB 80 29 07 00 2F 1A 2A 3A 04 14 24 34 00 0E 04 2E 07 08 18 28 38 00

00 10 20 30 00 89 B0 29 89 02 89 C9 89 00 73 1B 2B 3B 05 15 25 35 3F 0F F7 2F C0 09 19 29 39 FF

01 02 ............?... 11 12 ................ 21 22 ............. !" 31 32 #$%&'()*+,-./012 00 C0 3456789:; x-terminal.shell: S 1382727010:1382727010(0) win 4096 14:18:36.755522 server.login > x-terminal.shell: . ack 2024384001 win 4096

Here, Mit nick exploit s t he t rust relat ionship bet ween x- t erm inal and server. The SYN packet is sent wit h a spoofed source address. The at t acker sends t his packet blindly; t here is no way for t he at t acker t o see t he reply ( short of a snif- fer plant ed on x- t erm inal or server's net work) . Because Mit nick has used a fake source address, t hat of server, t he SYN/ ACK is sent t o server. Server knows t hat it never sent a SYN packet , a request t o open a connect ion. The proper response for server is t o send a RESET and break off t he connect ion. However, t hat isn't going t o happen. As shown here, 14 seconds before t he m ain part of t he at t ack, t he server's connect ion queue for t he login port is filled wit h a SYN flood. The server cannot speak.

14:18:22.516699 win 4096 14:18:22.566069 win 4096 14:18:22.744477 win 4096 14:18:22.830111 win 4096 14:18:22.886128

130.92.6.97.600 > server.login: S 1382726960:1382726960(0) 130.92.6.97.601 > server.login: S 1382726961:1382726961(0) 130.92.6.97.602 > server.login: S 1382726962:1382726962(0) 130.92.6.97.603 > server.login: S 1382726963:1382726963(0) 130.92.6.97.604 > server.login: S 1382726964:1382726964(0)

win 4096 14:18:22.943514 130.92.6.97.605 > server.login: S 1382726965:1382726965(0) win 4096

Th e r - Ut ilit ie s You would t hink t hat bot h t elnet and r- ut ilit ies would have been com plet ely replaced by a secure shell by now, but t his sim ply is not t he case. Bot h are st ill in wide use. The login service is also known as rlogin, and shell as rshell. These rem ot e " convenience services" allow access t o syst em s wit hout a pesky password, which can get old if you have t o ent er it oft en. On UNI X com put ers, you can generally creat e a t rust relat ionship for all users except root , or super user, by adding t he t rust ed syst em and possibly t he t rust ed account in a file called / et c/ host s.equiv. A root t rust ed relat ionship requires a file called / .rhost s. The r- ut ilit ies are obsolet e and should not be used anym ore; t he secure shell service is a far wiser choice because it is harder for t he at t acker t o exploit . I n eit her t he / host s.equiv or t he / .rhost s file, t he plus sign ( + ) has a special m eaning, t hat of t he wildcard. For inst ance, a / .rhost s file wit h a " + + " m eans t o t rust all com put ers and all users on t hose com put ers. Wit h t he real server disabled by t he SYN flood, t he t rust ed connect ion is used t o execut e t he following UNI X com m and wit h rshell: rsh x- t erm inal " echo + + > > / .rhost s" . The result of t his causes x- t erm inal t o t rust , as root , all com put ers and all users on t hese com put ers ( as already discussed) . That t race is as follows:

14:18:37.265404 server.login > x-terminal.shell: P 0:2(2) ack 1 win 4096 14:18:37.775872 server.login > x-terminal.shell: P 2:7(5) ack 1 win 4096 14:18:38.287404 server.login > x-terminal.shell: P 7:32(25) ack 1 win 4096

At t his point , t he connect ion is t erm inat ed by sending a FI N t o close t he connect ion. Mr. Mit nick logs on t o x- t erm inal from t he com put er of his choice and can execut e any com m and. The t arget syst em , x- t erm inal, is com prom ised:

14:18:41.347003 server.login > x-terminal.shell: . ack 2 win 4096 14:18:42.255978 server.login > x-terminal.shell: . ack 3 win 4096 14:18:43.165874 server.login > x-terminal.shell: F 32:32(0) ack 3 win 4096

I f Mit nick were now t o leave t he com put er nam ed server in it s m ut e st at e and som eone else were t o t ry t o rlogin, he would fail, which m ight bring unwant ed at t ent ion t o t he sit uat ion. Therefore, t he connect ion queue is em pt ied wit h a series of RESETs. We now see RSTs t o reset t he " half- open" connect ions and em pt y t he connect ion

queue for server.login:

14:18:52.298431 win 4096 14:18:52.363877 win 4096 14:18:52.416916 win 4096 14:18:52.476873 win 4096 14:18:52.536573 win 4096

130.92.6.97.600 > server.login: R 1382726960:1382726960(0) 130.92.6.97.601 > server.login: R 1382726961:1382726961(0) 130.92.6.97.602 > server.login: R 1382726962:1382726962(0) 130.92.6.97.603 > server.login: R 1382726963:1382726963(0) 130.92.6.97.604 > server.login: R 1382726964:1382726964(0)

D e t e ct in g t h e M it n ick At t a ck As we have m ent ioned, t his chapt er serves double dut y: t o t ell t he st ory of t he Mit nick at t ack and also t o set t he st age for t he final sect ion of t he book. As we com plet e t his chapt er, let 's int roduce t he elem ent s needed t o det ect and respond t o an at t ack like t his. The at t ack could have been det ect ed by bot h host - based and net work- based int rusion- det ect ion syst em s. I t could have been det ect ed at several point s, from t he int elligence- gat hering phase all t he way t o t he corrupt ion of / .rhost s file, when t he t arget syst em was fully com prom ised. I nt rusion det ect ion is not a specific t ool, but a capabilit y, a blending of t ools and t echniques. I n fact , a num ber of vendors, including NAI and I SS, offer hybrid syst em s t hat can perform log file analysis and packet analysis at t he host syst em . As you read t hrough t he m at erial in t his book, you will see exam ples of det ect s by firewalls and by host based and net work- based int rusion- det ect ion syst em s. TCP spoofing is becom ing harder all t he t im e because m any operat ing syst em s now random ize t heir init ial sequence num bers, t hough Microsoft is a not able except ion. Wit h vulnerable operat ing syst em s, t his is st ill a valuable t echnique for t he m ore advanced at t acker. SYN floods st ill work on m any TCP st acks, alt hough m odern operat ing syst em s are m uch m ore resist ant . And of course, even if a SYN flood will not work t o t ake out one side of a t rust relat ionship, t here are denial- ofservice at t acks t hat can shut down an operat ing syst em . Much safer alt ernat ives exist ( secure shell, for exam ple) , but syst em adm inist rat ors cont inue t o use t he rut ilit ies. I f we cannot field a capabilit y t hat enables us t o det ect t he Mit nick at t ack, what can we det ect ? To rest at e, t he Mit nick at t ack serves as an excellent indicat or of int rusion- det ect ion capabilit y. Why m ake such a big deal of t his? I t t urns out t hat alm ost a decade lat er, TCP hij acking is st ill alm ost im possible t o reliably det ect in t he field wit h a single t ool.Various product s can dem onst rat e a det ect in a lab, but t he num ber of false alarm s ( false posit ives) in t he field m akes t his syst em feat ure close t o useless. The good news is m ost of t he Mit nick at t ack was t rivially det ect able; so, let 's look at som e ways t o accom plish t his.

N e t w or k - Ba se d I n t r u sion - D e t e ct ion Syst e m s

Net work- based int rusion- det ect ion syst em s can reliably det ect t he following ent ire recon probe t race. As an analyst , you will be t em pt ed t o ignore a single finger at t em pt , but t he pat t ern in ent iret y really st ands out and should never be ignored. Consider som e of t he ways net work- based int rusion- det ect ion syst em s m ight det ect t his recon probe:

14:09:32 14:10:21 14:10:50 14:11:07 14:11:38 14:11:49 14:12:05

toad.com# toad.com# toad.com# toad.com# toad.com# toad.com# toad.com#

finger -l @target finger -l @server finger -l root@server finger -l @x-terminal showmount -e x-terminal rpcinfo -p x-terminal finger -l root@x-terminal

Tr u st Re la t ion sh ip The scan is t arget ed t o exploit a t rust relat ionship. The whole point of t he Mit nick probe was t o det erm ine t he t rust relat ionship bet ween syst em s. There m ust have been som e form of earlier int elligence gat hering t o det erm ine which syst em s t o t arget . I f Mit nick could do t his from a net work, t he sit e should be able t o do t he sam e t hing, perhaps even bet t er. Trained analyst s who know t heir net works can oft en look at an at t ack t o det erm ine whet her it is a t arget ed at t ack, but int rusiondet ect ion syst em s don't current ly have t his capabilit y. Por t Sca n I nt rusion- det ect ion syst em s can usually be configured t o wat ch for a single at t acker com ing t o m ult iple port s on a host . Port scans are a valuable t ool for det ect ing int elligence gat hering.You saw t oad.com fire t hree probes t o x- t erm inal. However, t wo of t hem ( showm ount and rpcinfo) will probably be direct ed at t he sam e port ( port m apper) , which is at TCP/ UDP 111. I t is cert ainly possible t o set t he alarm t hresholds t o report connect ion at t em pt s t o t wo different port s on a host com put er in under a m inut e. I n act ual pract ice, however, t his would creat e a large num ber of false alarm s. I t wouldn't t ake long for t he analyst t o give up and set t he t hreshold higher. Therefore, a net work- based int rusion- det ect ion syst em probably would not det ect t his probe as a port scan. H ost Sca n Host scans happen when m ult iple syst em s are accessed by a single syst em in a short period of t im e. I n t he exam ple, t oad.com connect s t o t hree different syst em s in as m any m inut es. Host scan det ect s are ext rem ely powerful t ools t hat force at t ackers t o coordinat e t heir probes from m ult iple addresses t o avoid det ect ion. I n operat ional experience, we have found t hat one can em ploy a com plet ely st upid brut e- force algorit hm ( flag any host t hat connect s t o m ore t han five host s in an hour, for exam ple) wit h a very accept able false posit ive rat e. I f you lower t he

window from an hour t o five m inut es, connect s t o t hree or m ore host s will st ill have a low false posit ive rat e for m ost sit es. I f t he int rusion- det ect ion syst em can m odify t he rule for a host scan t o elim inat e t he host s or condit ions t hat oft en cause false posit ives ( for exam ple, popular web servers, real audio, any ot her broadcast service) , t he t rip t hreshold m ight be able t o be set even lower t han five per hour and t hree per five m inut es. The host scan det ect ion code in an int rusiondet ect ion syst em should be able t o det ect t he exam ple recon probe. Con n e ct ion s t o D a n ge r ou s Por t s The recon probe t arget s well- known, exploit able port s. For t his reason, t he recon probe is very close t o a guarant eed det ect . Net work- based int rusion- det ect ion syst em s can and do reliably det ect connect s and at t em pt ed connect s t o SUNRPCs. On t he whole, t he at t acker has som e advant ages in t erm s of evading int rusiondet ect ion syst em s; she can go low and slow, and she can flood t he syst em wit h red herring decoys and t hen go for her act ual t arget . She probably has t o go aft er a well- known port or service t o execut e t he exploit , however, and t his is where t he int rusion- det ect ion syst em has an advant age. SUNRPCs are a very well- known at t ack point and every int rusion- det ect ion syst em should be able t o det ect an at t em pt against t hese services.

H ost - Ba se d I n t r u sion - D e t e ct ion Syst e m s Because t he at t ack was against a UNI X syst em , t his review considers det ect ing t he at t ack wit h t wo t ypes of com m only used UNI X t ools: TCP Wrappers and Tripwire. TCP Wrappers log connect ion at t em pt s against prot ect ed services and can evaluat e t hem against an access cont rol list t o det erm ine whet her t o allow a successful connect ion. Tripwire can m onit or t he st at us of individual files and det erm ine whet her t hey were changed. When considering host - based int rusiondet ect ion syst em s, you want at least t hese capabilit ies. Using t ools such as Port Sent ry and LogSent ry from ht t p: / / www.psionic.com / , you can achieve an even great er level of det ect ion and prot ect ion by wat ching t he logs and t he packet s addressed t o t he host syst em . TCP W r a ppe r s TCP Wrappers or xinet d would det ect t he probes or at t acks at t he host level. For TCP Wrappers t o work, you m ust edit t he / et c/ inet d.conf file t o wrap t he services t hat were probed, such as finger. I t is also a good idea t o add access cont rol list s t o TCP Wrappers. I f a syst em is going t o run a service such as finger, you can define which syst em s you will allow t o access t he finger daem on. That way, bot h t he access would be logged and t he connect ion would not be perm it t ed. The following fabricat ed log ent ry shows what t hree TCP Wrappers finger connect ion event s m ight look like on a syst em log facilit y ( syslog) :

Dec Dec Dec

24 14:10:29 target in.finger[11244]: refused connect from toad.com 24 14:10:35 server in.fingerd[21245]: refused connect from toad.com 24 14:11:08 x-terminal in.fingerd[11066]: refused connect from toad.com

One of t he int erest ing problem s wit h host - based int rusion det ect ion is how m uch inform at ion t o keep and analyze locally and how m uch t o analyze cen- t rally. This fabricat ed exam ple shows t hat t hree different syst em s ( t arget , server, and xt erm inal) are report ing t o a cent ral log server. A single finger at t em pt logged and evaluat ed on t he host com put er m ight be ignored. Three finger at t em pt s against t hree syst em s m ight st and out , however, if t hey were recorded and evaluat ed on a cent ral or depart m ent al log server. An analyst would consider access at t em pt s t o port m apper higher priorit y t han finger at t em pt s. At t he t im e of t he Mit nick at t ack, secure port m appers were not widely available. This is no longer t he case, and so it would be an indicat ion of an archaic or poorly configured UNI X operat ing syst em if bot h logging and access cont rol feat ures were not available for port m ap. Host - based int rusion- det ect ion solut ions should cert ainly det ect at t em pt s t o access port m ap. Tr ipw ir e You could not reasonably use Tripwire t o det ect t he recon probes. This is because it basically creat es and st ores a high- qualit y checksum of crit ical files, so t hat if t he file or it s at t ribut es change, t his fact can be det ect ed. Tripwire could det ect t he act ual syst em com prom ise, t he point at which t he / .rhost s file was overwrit t en. Unfort unat ely, even if t he alarm goes off in near real- t im e, it is essent ially t oo lat e. The syst em is already com prom ised, and a script ed at t ack can do a lot of dam age very rapidly. Therefore, early det ect s are t he best det ect s. I f you can det ect an int ruder in t he recon phase of his at t ack and det erm ine t he syst em s t he at t acker has an int erest in, your chance of det ect ing t he act ual at t ack im proves.

Pr e ve n t in g t h e M it n ick At t a ck Cert ainly, t he at t ack could have been prevent ed at m ult iple point s. A wellconfigured firewall or filt ering rout er is rem arkably inexpensive, easy t o configure, and effect ive at prot ect ing sit es from inform at ion- gat hering probes and at t acks originat ing from t he I nt ernet . Even for it s t im e, t his sit e was left open t o m ore services t han was advisable. I f t he recon probes and r- ut ilit ies had been blocked, it would have been m uch harder for t he at t acker, perhaps im possible. I n general, a sit e should be blocking alm ost all incom ing packet s except for packet s dest ined for port s t hat need t o be open. A file t hat will point out som e of t he m ore dangerous port s, called t he Top Twent y list , www.sans.org/ t op20.ht m , will give you point ers on not j ust what t o block, but also port s t o wat ch at t em pt s t o connect t o. As we will see in Chapt er

16, " Archit ect ural I ssues," t he perim et er is a core part of an int rusion- det ect ion capabilit y. You have already read about host - based securit y and t he use of access list s. Obviously, syst em s need t o run services t o accom plish t heir work efficient ly, but it is oft en possible t o specify which syst em s are allowed t o access a part icular service ( for exam ple, by using TCP Wrappers) . I n t his case, t he at t acker m ust act ually com prom ise a t rust ed host and launch t he at t ack from t hat host . The Mit nick at t ack j ust had t o spoof t he ident it y of a t rust ed host , which is a lot easier t han act ually com prom ising t he t rust ed host . Even aft er t he at t ack was launched, if it had been det ect ed and responded t o, it could have been st opped. I n Chapt er 18, "Aut om at ed and Manual Response," we will discuss ways t o slow down, or even st op, an at t ack t hat is in progress.

Su m m a r y When doing a post m ort em on a successful syst em com prom ise or at t ack, you can oft en det erm ine t hat t he at t ack was preceded by int elligence gat hering " recon" probes. The harder issue is t o det ect recon probes, t ake t hem seriously, and increase t he defensive post ure of a facilit y or syst em . Many t im es t hese recon probes are used t o locat e and invest igat e t rust relat ionships bet ween com put er syst em s. At t ackers oft en exploit a t rust relat ionship bet ween t wo com put ers. Many t im es, syst em adm inist rat ors use such relat ionships as a convenience for t hem selves, even t hough t hey are aware t hat t his is a " chink in t he arm or" for t he syst em . The Mit nick at t ack deliberat ely did not com plet e t he TCP t hree- way handshake t o SYN flood one side of t he t rust relat ionship. Many at t acks and probes int ent ionally do not com plet e t he t hree- way handshake. Craft ed packet s include packet s wit h deliberat ely false source addresses. These oft en have a signat ure t hat allows int rusion det ect ion t o det ect t heir use. Checking t hings only once is a general problem in com put er securit y. When designing soft ware or syst em s, build in t he capabilit y t o check and t hen recheck. The signat ure of TCP hij acking is t hat t he I P addresses change during a TCP session, while t he sequence num bers rem ain correct for t he connect ion. Reliable det ect ion of TCP hij acking is st ill beyond t he reach of single- t ool syst em s in realworld environm ent s. I nt rusion det ect ion is best t hought of as a capabilit y, not a single t ool. The Mit nick at t ack serves as an excellent t est case. I nt rusion- det ect ion syst em s t hat cannot det ect t his at t ack on a real- world net work wit h a real- world load ( such as a busy

T- 1 or higher) , j ust m islead t heir users int o t hinking t hey are perform ing int rusion det ect ion when in fact t hey are blind. Even t he best int rusion- det ect ion syst em will be blind t o an at t ack t hat it is not program m ed t o det ect . Many int rusion- det ect ion analyst s prefer t o use syst em s t hat enable t hem t o craft user- defined filt ers t o det ect new or unusual at t acks. The next chapt er present s exam ples of userdefined filt ers.

Ch a pt e r 1 6 . Ar ch it e ct u r a l I ssu e s

This chapt er considers som e of t he t radeoffs, capabilit ies, and issues facing int rusion- det ect ion syst em users and builders. This is a bit m ore t heoret ical t han som e part s of t he book, but I use real- world exam ples t o t ry t o keep t he m at erial useful and pragm at ic. We invest som e t im e t alking about event s of int erest ( EOI ) . This is an im port ant concept because an analyst get s bet t er result s from an int rusion- det ect ion syst em if she underst ands what she is searching for and t unes t he I DS t o find it , as opposed t o let t ing t he I DS t ell t he analyst what t o look for. We also discuss severit y. All incident s are not creat ed equal and should not be t reat ed so. There is a great debat e, a religious war in int rusion det ect ion, about whet her t he sensor should be placed inside or out side t he firewall. This chapt er covers t his and ot her sensor- placem ent issues as well. One of t he great m yt hs t hat have occurred in t he indust ry is t he need t o work in real- t im e. I have even seen t his specified in procurem ent docum ent s. What m arket ers m ean by real- t im e is t hat int rusion- det ect ion analyst s are supposed t o respond t o beeps and alarm s. Real- t im e, of course, is alm ost im possible, at least for hum an react ion, because t he packet is t raveling at t he speed of light . Figure 16.1 shows t he det ect occurring j ust aft er real- t im e. The illust rat ion was added t o t he book in case you ever need t o point t his out t o your m anagem ent because t hey are overem phasizing response t im e. I n fact , UNI X and Windows NT com put er syst em s do not support eit her real- t im e or even det erm inist ic delay. We discuss t hese issues in push versus pull archit ect ures, which leads int o a sect ion on t he analyst console. Moreover, as we will short ly discuss, t he int rusion analyst will run filt ers t hrough second and even t hird passes over t he dat a looking for EOI . Figu r e 1 6 .1 . Tim e a n d I D r e spon se .

Every int rusion- det ect ion m aker falls short in providing a really great analyst int erface. This is current ly t he prim ary t hrust of developm ent of course, so we will t ake som e t im e t o discuss t he int erface. What exact ly does an analyst need? The next sect ion discusses som e of t he t radeoffs, or " t uning knobs," t hat should be considered as you design or enhance your int rusion- det ect ion capabilit y. These include false posit ives and negat ives and sensor focus.

Eve n t s of I n t e r e st Chapt ers 13, "I nt roduct ion t o Snort and Snort Rules," and 14, " Snort Rules Part I I ," int roduced event s of int erest in t he sense t hat when you writ e a filt er, you design it t o find som et hing you are int erest ed in. For inst ance, if you are using t he Snort rule cont ent opt ion t o find t he hex pat t ern 0xdead or 0xbeef, a pat t ern t hat has it s root s as a t est pat t ern but is som et im es used by at t ackers in t heir code, and you com e across a packet wit h t his pat t ern, t his is pot ent ially an EOI . There are t hree m ain issues surrounding t he subj ect of EOI in int rusion det ect ion: z

The balance bet ween false posit ives and false negat ives

z

Target ing or focusing t he sensor t o ensure we det ect EOI

z

The effect s of t he lim it s of our syst em on our capabilit y t o det ect

The false negat ive/ false posit ive problem is a serious one in int rusion det ect ion and a lot of our energy is invest ed in cust om izing filt ers t o det ect EOI and not t o generat e false alarm s or false posit ives. On t he ot her hand, false negat ives would m ean m issing som et hing we would have want ed t o det ect . I would like t o illust rat e what an analyst m ight do wit h a sim ple exam ple. At t ackers are known t o use cert ain st rings, num bers, and hex pat t erns in t he soft ware t hey creat e t o do reconnaissance, denial of service, or direct exploit s. Som e of t he classics are: z

The decim al pat t erns 31337 and 666

z

The ASCI I st ring, skillz

z

The hex pat t erns 0xdead and 0xbeef

Suppose we creat e a filt er looking for hex 0xdead as shown below:

alert icmp any any -> 192.168.5.0/24 any (msg: "0xdead hex pattern seen"; content: "|DE AD|";)

\ \

Would such a rule creat e false posit ives? Cert ainly it would. I f t he cont ent of an I CMP packet happened t o have t hese hex charact ers in t his order, t hese sim ple cont ent filt ers would alert . Would I want t o run t his rule in real- t im e? No, probably not . On t he ot her hand, if we st art ed seeing a lot of 0xdead 0xbeef, t hat could be significant . One of t he lessons from t he Shadow proj ect was secondary analysis. Keep a couple of days of dat a and run program s t o scrub t he dat a looking for int erest ing event s. I probably wouldn't even bot her m anually exam ining a single occurrence of 0xdead or 666 in a couple of day's wort h of dat a, but if I saw a dozen, I would cert ainly t hink about pulling t hose connect ions and exam ining t hem . The st ories you learned about in Chapt ers 10, " Real- World Analysis," and 11, " Myst ery Traffic," alm ost all have t he sam e root . An analyst , looking at t he dat a, saw som et hing odd and said, " That 's funny." When Judy and I were working t oget her as act ive analyst s for t he Arm y and Navy respect ively, we discovered a num ber of at t acks for t he first t im e. People would ask how we did it . I used t o answer, " Pure, dum b luck." Now you know bet t er. We would writ e script s t o slice and dice t hat dat a looking for t hose event s of int erest . Anot her great classic script is t o t ake a week or so of dat a and search for odd prot ocol act ivit y as shown in t he following .bpf filt er:

not tcp and not udp and not icmp and not igrp and not igmp

You cert ainly would not want t o run t his in real- t im e; but , as a way t o run t hrough your dat a looking for event s of int erest t hat you m ight ot herwise m iss, t his is obviously at t ract ive. Aft er you know your net work and get your filt er opt im ized, m ost likely you will rarely det ect anyt hing wit h t his filt er. I don't recom m end t hat you run it int eract ively and wat ch t he result s, because you m ight get bored and quit running it . However, if you schedule t he j ob t o run once a week and only design t he syst em t o alert you if it finds result s, you have a t ool t hat m ight st rike pay dirt one fine day. I f you are shopping for t hese new correlat ion consoles or ent erprise securit y m anagers, one feat ure you m ight want t o look for is t he capabilit y t o schedule and run script s t o exam ine your dat a. Now we com plet e our st udy of EOI wit h a considerat ion of overall syst em

lim it at ions on t he lower det ect lim it . Let 's st art wit h t he bot t om line: I t is im port ant t o have a fairly clear underst anding of what you are looking for and what event s you are int erest ed in, because you cannot collect or det ect everyt hing. Figure 16.2 shows bot h t he dat a act ually observable by your int rusiondet ect ion syst em and t he dat a you cannot observe. Figu r e 1 6 .2 . Sou r ce s of da t a .

Lim it s t o Obse r va t ion As shown in Figure 16.2, t he sensor or event generat or m ight not be able t o observe all event s. This is oft en quit e a surprise for folks who pay good m oney for an int rusion- det ect ion syst em , and t hey slowly find out j ust how lim it ed it is in pract ice. What kinds of t hings can't we observe? z

z

Event s on a different net work. Unaut horized " backdoor" connect ions int o a net work are very com m on; every m achine wit h a m odem has t he pot ent ial t o perm it a backdoor. This issue shows up prom inent ly in advert isem ent s for host - based int rusion- det ect ion syst em s because t hey can m ake t he " we're here, we're t here, we're everywhere" claim . Sensor is not funct ioning. Event s t hat happen right in front of t he I DS, but t hey are not observed because t he I DS is brain dead. By brain dead, I m ean anywhere bet ween hard crashed like t he blue screen of deat h, t o pingable while not funct ioning. A good m easure of I DS reliabilit y m ight m ean t im e bet ween having t o reboot t he syst em , because t hat seem s t o be t he fix for bot h Windows NT- and UNI X- based syst em s. I have personally experienced t his j oy m ult iple t im es wit h Shadow, NFR, NI D, Snort , and RealSecure. Nat urally, you only discover t hese syst em s need reboot ing on rainy days when t hey are in a different building from your analyst console. Som e syst em s are m ore robust t han ot hers, of course. What is t he m ost effect ive Windows NT rem ot e m anagem ent t ool? A car. I f t he sensor's disk fills up, t his will also prevent collect ion.

z

z

No habla SNA or SS7. Event s in a prot ocol t hat t he int rusion- det ect ion syst em cannot decode are not observable. What if you need an int rusion- det ect ion syst em t hat can decode Signaling Syst em 7 or I BM's SNA? I s t here a need for such a t hing? For m ost of us, t he answer is no; however, one fairly com m on event is when we det ect a prot ocol we don't know. For inst ance, I know a num ber of people who have det ect ed I P Prot ocol 54, NHRP ( Next Hop Resolut ion Prot ocol) , at t heir DMZs and have never seen an I DS decode t his. Exceeding bandwidt h lim it . Event s t hat occur above t he sensor's m axim um bandwidt h- handling capabilit y cannot be observed. At som e point , t he sensor has t o st art dropping packet s and we ent er what analyst s euphem ist ically call st at ist ical sam pling. I f you ask net work- based I DS vendors what t heir upper lim it s of speed are, you get a lot of curious answers ranging from " 80Mbps" t o " it depends." Hint : Trust t he person who says " it depends" m ore t han t he one who gives you a fixed num ber, especially a fixed num ber above T- 3 speeds ( 45Mbps) . The num ber of rules a sensor has t o process is one prim ary fact or in t he sensor's upper det ect ion lim it for m any syst em s, however t he prim ary fact or is t he crit ical pat h. This is t he longest execut ion pat h a given packet m ight cause t he sensor t o t ake. I f a sensor is st ill processing one packet when anot her arrives, t he packet will be dropped.

To recap what was j ust covered, int rusion- det ect ion syst em s cannot look at every possible event . The reasons for t his include t he following: z

The event happened on anot her net work.

z

The I DS is dead.

z

The I DS has no underst anding of t he prot ocol.

z

The I DS has reached it s m axim um bandwidt h lim it , or has hit crit ical pat h on a given packet and has dropped packet s t hat cam e lat er.

The bad news is t here are event s we can't even observe. The good news is t hat we find t here are event s t hat we can capt ure. Of all t he packet s t hat we can capt ure, som e will m at ch our filt ers in som e way, and t hey are represent ed by t he space of t he inner circle. Finally, som e of t he t ot al num ber of det ect s in t he inner circle are valid and have value. We can refer t o t hese as t he EOI , t he genuine, no- falseposit ive- about - it det ect s. They are t he reason we go t hrough all t he t rouble of deploying and operat ing int rusion- det ect ion syst em s. Det ect ing an at t ack, especially a clever at t ack, is a lot of fun.

Low - H a n gin g Fr u it Pa r a digm Today, t he prim ary st andard in int rusion det ect ion is t he Snort ruleset . There used t o be t wo m aj or ruleset s, but wit h t he present legal t roubles of Max Vision, his

ruleset is no longer available. I t has been inspiring t o wat ch t he com m unit y com e and work t oget her t o build t he rules, im prove t he port list , and explain t he vulnerabilit ies. I n som e sense, I feel like a heel saying a single word against t his wort hy effort , but t here is a risk t o us t hat we at least need t o be aware of. We have already discussed t he basic issues of false posit ives and negat ives when we covered signat ures and filt ers t o det ect signat ures. Now we need t o consider t he effect of t he low- hanging fruit paradigm on false negat ives. What do we m ean by t he low hanging fruit ? I live on t he island of Kauai. Many t hings are in short supply, but we cert ainly have enough banana t rees and free range chickens. Aft er a hurricane seven years ago, m any of t he chicken coops were blown apart freeing t he chickens. There are no nat ural predat ors, so now t he island is overrun by chickens. My neighbor recent ly had a bum per crop of bananas in his garden. I have never st opped t o t hink about j ust how m any bananas can grow on one of t hese t rees, but it can be m ore t han one hundred pounds. As t he t ree began t o bend a bit wit h t he weight of t he bananas, t hey cam e in range of t he chickens, at least t he lower ones. They would line up under t he banana t ree and j um p/ part ially fly and nip at t he exposed bananas. I t was quit e a sight t o wat ch and m any a banana was ruined as it s bot t om was nipped off. So, t he low hanging fruit is t he easily harvest ed, vulnerable fruit t hat any one or any t hing can reach. Suppose a num ber of int rusion- det ect ion vendors were secret ly downloading t he Snort ruleset and using t his as a foundat ion for t heir own rules. What if t heir ot her m aj or process was t o go t o a couple of well known sit es for at t ack code t o download t he exploit s t o t heir labs, run t he exploit s, det erm ine t heir signat ures, build effect ive filt ers t o det ect t hese exploit s, and t hen load t hese filt ers in t he int rusion- det ect ion syst em s we all use? I f t his were t o happen, we would begin t o est ablish a lowest com m on denom inat or. At first blush, t hat sounds like a good t hing; as a consum er, you could expect any I DS t o m eet at least a m inim um st andard defined by t he Snort ruleset and t he m ost available at t acks ( m ost of which are covered in t he Snort ruleset , of course) . The problem is t hat an at t acker can t hen analyze t he Snort ruleset and craft sm all changes t o her at t acks t o m ake t hem evade t he I DS. I f a num ber of com m ercial vendors copy t hese rules, t his becom es an int erest ing problem . I t allows t hem t o t reat t he ruleset , a t rem endous asset t o t he com m unit y, as low hanging fruit . Alt hough t he preceding paragraph is part ially t rue, t here are lot s of ways t o m it igat e t he problem . Many int rusion- det ect ion vendors and researchers cult i- vat e cont act s wit h t he com put ing underground and have access t o a larger library of at t acks t han t hose com m only published. Several research effort s at t em pt t o collect at t acks and exploit s and t o define vulnerabilit ies. The problem is t hey use different nam es and descript ions. Mit re ( ht t p: / / cve.m it re.org) m anages a proj ect called t he Com put er Vulnerabilit ies and Exposures ( CVE) , which enj oys broad indust ry support . Their goal is t o develop a com m on nam - ing syst em , prim arily t o serve as a t hesaurus for vulnerabilit y descript ions, but also t o support I DS developm ent .

Also, it is som et im es possible t o writ e a general filt er t o det ect a fam ily of exploit s. We have already exam ined a general filt er t o det ect web server at t acks. During t he discussion of t hat filt er, you learned about a num ber of CGI - BI N at t acks against web servers t hat at t em pt t o acquire t he syst em 's password file for offline decrypt ion. The m ost fam ous is t he phf at t ack. Several hundred ot hers exist , however, including php and aglim pse. I n t he past , each of t hese had cgi- bin and / et c/ passwd files som ewhere in t he packet , so it was possible t o writ e a general filt er t o det ect each of t hese and t heir cousins as well. Today, wit h t he advent of shadow password files, we do not see m any at t acks against / et c/ passwd; however we com m only see t he following st ring:

id;uname –a; w

The com m and id gives you your effect ive userI D; t he sem icolon delim it s different com m ands; unam e –a gives t he exact operat ing syst em and pat ch level; and finally w t ells you who is logged on t o t he syst em . I t is also possible ( and very advisable) t o writ e general filt ers t hat det ect odd event s ( t hings t hat j ust shouldn't happen) and t o report t hem . A TCP packet wit h all flags set , or no flags set , and packet s wit h unknown I P prot ocols are exam ples of t hese kinds of filt ers. Alt hough you can increase t he sensor- det ect ion capabilit y in m any ways, t he bot t om line should be som ewhat sobering: I f an I DS depends on signat ures and doesn't have a filt er t o look for t hat signat ure, how will it m ake a det ect ?

H um a n Fa ct or s Lim it D e t e ct s Anot her fact or t hat lim it s t he EOI we can det ect and report is t hat people are part of t he syst em . A t ypical day as an operat or of an int rusion- det ect ion syst em includes t he recording and possible report ing of som e num ber of det ect s. I f you were t o exam ine a year's wort h of det ect s from a sit e, you m ight find t hat t he det ect s clust er as 12 I MAPs, 5 port m aps, 25 I CMP ping sweeps, 30 Sm urfs, 8 m scans, 4 port scans, 5 DNS zone Xfer at t em pt s, 4 WinNukes, and so fort h. I f you check t he sit e's Com put er I ncident Response Team ( CI RT) , you find t hat yup, t hese are t he kinds of t hings being reported by t hose sit es t hat do bot her t o report . So what 's wrong wit h t his pict ure? Not only does t he I DS fail t o report m any event s of int erest because it does not have a signat ure for t hem , m any t im es t he analyst chooses not t o report m any of t he event s t hat are det ect ed. I f you were t o spend a day or t wo on t he I nt ernet doing web searches, you could easily collect a hundred different soft ware im plem ent at ions of exploit s. Som e won't com pile easily, and ot hers have lim it ed docum ent at ion. St ill ot hers are variat ions on a t hem e. The sim ple fact rem ains, however, t hat you can easily collect m ore at t acks t han are com m only being det ect ed and report ed. So what 's t he problem ? One part of t he problem is t he signat ure issue previously discussed. I f t he design of t he syst em relies on signat ures and a filt er doesn't exist , t he box cannot m ake t he det ect . Ot her fact ors t hat lim it t he det ect capabilit y of t he

syst em as a whole relat e t o t he int rusion- det ect ion analyst s and t he CI RTs t o which t hey report . Lim it a t ion s Ca u se d by t h e An a lyst Part of t he reason for m issed det ect s has t o be laid at t he feet of t he int rusiondet ect ion analyst . There are several issues here. Som et im es, an analyst m ight m ent ally evaluat e an int rusion at t em pt and decide it isn't wort h invest igat ing. I have been guilt y of t his m ult iple t im es. Here is a classic exam ple: Code Red is st ill act ive, because som e people don't have t he gum pt ion t o pat ch t heir I I S boxes. On a given day, I see a num ber of det ect s on port 80, but I do not t end t o evaluat e t hem in dept h. I j ust figure it is Code Red. However, in February 2002, when t he Apache PHP vulnerabilit y was report ed, I had t o suddenly change m y ways. Aft er all, I run Apache. Does an analyst report som et hing he doesn't underst and? Unknown pat t erns are challenging and require a significant underst anding of TCP/ I P and com put er syst em processes t o run t o ground. What if t he analyst doesn't t rust her int rusiondet ect ion syst em ? I t t akes a lot of fait h t o sign a report based on a lit t le pict ure on a console t elling you such and such j ust happened. I t t akes even m ore fait h t o do t his when t he sam e I DS report s t wo em ail Wiz at t acks ( Wiz is a very, very old em ail at t ack) per day and six SYN floods per hour ( and t hese are obviously false posit ives) . Therefore, analyst s are m ost cert ainly a weak link in t he syst em . The reasons for t his include t he following: z

Failing t o report what t he I DS det ect s

z

Lack of t raining needed t o invest igat e new at t ack pat t erns

z

Lack of underst anding about TCP/ I P, prot ocols, and services

z

Lack of t rust in t he I DS it self

Lim it a t ion s Ca u se d by t h e CI RTs Could part of t he problem of m issed det ect s be t he CI RTs? I f your CI RT get s a report for an I MAP, port m ap, I CMP ping sweep, Sm urf, m scan, port scan, DNS zone Xfer, WinNuke, or what ever, no problem . They have a dat abase pigeonhole t o put it in, and everyone is happy. I f t he CI RT get s a report saying, " Unknown probe t ype, here is t he t race, what ever it is it t urns m y screens blue," what do t hey do wit h t hat ? The person get t ing t he report is probably ent ry level and so t here is a hassle because a dat abase pigeonhole doesn't exist . The advanced analyst s have a lot of work t o do, and t he seasoned CI RT workers have been burned by a false posit ive or t wo and aren't t hat likely t o t ake act ion unless t hey get a sim ilar report from a second source. I n int rusion t im e, t his can be a serious problem . From t he m om ent I first heard about t he klogin vulnerabilit y in May 2000, it was less t han eight hours before we were dealing wit h our first com prom ised syst em .

This is a serious issue because t he CI RT is alm ost cert ainly underst affed. Real people are on t he phone begging for help because t heir syst em s are com prom ised and t heir organizat ion never had t he funding t o t ake securit y seriously. Real people scream ing for help wit h com prom ised syst em s has t o t ake priorit y over unknown probe t ypes t hat t urn screens blue. At t he end of t he m ont h or quart er or what ever, t he CI RT put s out t heir report : We logged t his m any port m aps, I CMP ping sweeps, Sm urfs, m scans, port scans, DNS zone Xfers, WinNukes, and so fort h. The new analyst who report ed t he unknown probe t ype sees t hat t he report m akes no m ent ion of t he unknown probe, shakes her head, and silent ly decides, never again. The analyst doesn't know whet her t he CI RT t hinks she is nut s or whet her t he CI RT j ust doesn't care. This is why we m ade a conscious choice wit h I ncident s.org, an all volunt eer CI RT and analysis organizat ion, t o be willing t o post a new pat t ern before t he whole world and writ e as our com m ent ary, " We have no idea what t his is, can anybody help us?" More t han once I have been em barrassed by t he answer, because it was a pat t ern I should have known. Over t im e, t hat has led us t o act m ore like a convent ional CI RT, t o be caut ious about what we post , t o wait unt il we know m ore. This keeps t he word from get t ing out , and m ay allow an at t ack m ore t im e before we underst and it well enough t o det ect it and defend against it . We know we shouldn't clam up, but it is hard t o fight hum an nat ure. A brief recap of EOI is now in order. We cannot observe every event . Of t he t hings t hat we can observe, som e are dism issed as unim port ant when in fact t hey are at t acks—t hese are t he false negat ives. Ot hers are flagged as at t acks when t hey aren't —t hese are t he false posit ives. The goal of t he syst em designer and int rusion- det ect ion analyst should be t o m axim ize t he event s t hat can be observed while m inim izing t he false posit ives and negat ives. A num ber of syst em s and program design issues arise here, but t here are also hum an issues t o consider. Alt hough com plet e efficiency m ight never be achieved, you should accept not hing less as your goal.

Se ve r it y Several schools of t hought propose ways t o reduce severit y t o a m et ric, a num ber we can evaluat e. This sect ion discusses som e of t he prim ary fact ors t hat should be used t o develop such a num ber. Let 's st art , however, wit h a basic philosophical principle: Severit y is best viewed from t he point of view of t he syst em ( and it s owners) under at t ack. This is an im port ant principle because t he furt her rem oved t he evaluat or is from a given at t ack, t he less severe it is ( at least t o t he evaluat or) .

I t H a ppe n s All t h e Tim e The int rusion- det ect ion t eam t hat I worked wit h for several years was once invit ed t o spend t he day wit h a very large CI RT. The CI RT had an analysis t eam t hat had j ust accept ed delivery of a spiffy new int rusiondet ect ion capabilit y, an analyst int erface t hat could wat ch a large num ber

of sensors. We all t hought it m ight be int erest ing t o sit wit h t he Shadow t eam analyst s at t his CI RT's workst at ions and see how effect ive t hey could be wit h t he new spiffy int erface. Wit hin four m inut es, one of t he Shadow analyst s had found a signat ure indicat ing a root - level break- in t o one of our sist er sit es. She want ed t o call t he sit e and t ell t hem , but t he CI RT workers laughed and said, " I t happens all t he t im e." No doubt t hat was t rue from t heir perspect ive. These folks operat e well over a hundred sensors of t heir own in addit ion t o all t he report s t hey receive. They probably deal wit h m ore com prom ises in a year t han I will experience in m y ent ire working career. The t rip st ill seem s odd t o m e, however, because I know how m uch t rouble and pain a com prom ised syst em can be t o t he syst em owners and t hose who have t o assist t hem . Severit y is best viewed from t he point of view of t he syst em under at t ack and it s owner( s) . Alt hough we do want t o keep t he hum an elem ent in m ind as we discuss t he severit y of at t acks, we need t o be able t o sort bet ween t hem so t hat we can react appropriat ely. At every em ergency room , t here is an individual in charge of t riage, m aking sure t hat care is given t o t hose who need it t he m ost . This way, a pat ient wit h an im m ediat e life- t hreat ening inj ury doesn't have t o wait while t he m edical personnel at t end t o a pat ient wit h a st ubbed t oe. I n a large- scale at t ack response, resources becom e scarce very quickly, so an approach t o t riage for com put er asset s is required. Figure 16.3 int roduces t his concept at a high level. Figu r e 1 6 .3 . Se ve r it y a t a gla n ce .

Are nont arget ed exploit s for vulnerabilit ies t hat do not exist wit hin your com put er syst em s act ually no- risk? When you st udy risk m ore form ally, you will learn t hat part of t he equat ion is your level of cert aint y; how sure are you t hat none of your syst em s have t he vulnerabilit y? I t end t o be on t he conservat ive side. I n t he exam ples t hat follow, I consider nont arget ed, nonvulnerable exploit s t o be of no

risk only if t hey are also blocked by t he firewall or filt ering rout er. I n fact , t here is a sense in which t his is negat ive risk. The at t acker using a nont arget ed script exploit against a well- secured sit e is at a higher risk t han t he sit e because t he at t ack will be report ed. I f t he at t acker succeeds in breaking in and doing dam age som ewhere else, t he odds are at least fair t hat he can be t racked down. What m ight be a reasonable m et hod t o derive a m et ric for severit y? What are t he prim ary fact ors? How can we est ablish an equat ion? How likely is t he at t ack t o do dam age? And, if we sust ain dam age, how bad will it hurt ? Clearly, t hese are all fact ors. Cr it ica lit y How bad will it hurt is one of t he m ost im port ant issues t o consider in risk m anagem ent . I was giving a t alk in Washingt on, DC and want ed t o m ake a point about ant i- virus and personal firewalls so I asked, " How m any of you t ravel m ult iple t im es a year?" Most of t he hands went up, which m akes sense for a governm ent headquart ers crowd. Then I asked, " How m any of you carry Cipro?" Cipro is t he ant ibiot ic t hat was prescribed during t he Ant hrax at t acks. Because t here had not been an ant hrax at t ack since Oct ober 2001, nobody was t hinking about t hat . However, I can j ust im agine what would happen if I were in a st range cit y and st art ed feeling t he worst case of t he flu in m y ent ire life. How would I get access t o t op- qualit y m edical care? At hom e, I have m y doct or, who knows m e, and a m edical record and friends t hat are doct ors. I n Houst on, or Seat t le, or New York Cit y, t he answer is go t o t he em ergency room . Do you know t hat it is not im possible t o wait 12 hours j ust t o be seen in an em ergency room ? How bad will it hurt ? This is t he quest ion t hat should drive us. Now, j ust so you don't t hink I am t ot ally off m y rocker for carrying Cipro, I also t ravel int ernat ionally a lot , and t hough I t ry not t o drink t he wat er and t o cook it , peel it or forget it , having som et hing like Cipro is an im port ant t ool if t hings go wrong. What does any of t his have t o do wit h ant ivirus or a personal firewall? I f you don't have t hese t hings and you are exposed, you are in a heap of t rouble, j ust like ant hrax and no Cipro. I t would be bad for m e t o be poisoned wit h ant hrax, but it would be so m uch worse for t he President of t he Unit ed St at es t o be poisoned wit h it . The m aj or det erm inant for " how bad will it hurt ?" is how crit ical t he t arget is. I f a deskt op syst em is com prom ised, it is bad in t he sense t hat t im e and work m ight be lost . Also, t hat syst em could be used as a springboard t o at t ack ot her syst em s. I f an organizat ion's dom ain nam e syst em ( DNS) server or em ail relay is com prom ised, however, a m uch m ore serious problem exist s. I n fact , if an at t acker can t ake over a sit e's DNS server, t he at t acker m ight be able t o m anipulat e t rust relat ionships and t hereby com prom ise m ost or all of a sit e's syst em s. When developing a m et ric, we need a way t o quant ify crit icalit y. We can use a sim ple five- point scale, as follows:

5 point s

Firewall, DNS server, core rout er

4 point s

Em ail relay/ exchanger

2 point s

User UNI X deskt op syst em

1 point

MS- DOS 3.11

Le t h a lit y The let halit y of t he exploit refers t o how likely t he at t ack is t o do dam age. At t ack soft ware is generally eit her applicat ion or operat ing syst em specific. A Macint osh deskt op syst em isn't vulnerable t o a UNI X t oolt alk buffer overflow, or an rcp.st at d at t ack. A Sun Microsyst em s box running unpat ched Solaris m ight quickly becom e t he wholly owned propert y of Hacker I ncorporat ed if hit wit h t he sam e at t acks. As an int rusion- det ect ion analyst , I get nervous when an at t acker can go aft er a specific t arget wit h an appropriat e exploit . This is an indicat or t hat t he at t acker has done his hom ework wit h recon probes and t hat we are going t o have t o t ake addit ional count erm easures t o prot ect t he t arget . Again, a five- point scale applies:

5 point s

At t acker can gain root across net work.

4 point s

Tot al lockout by denial of service.

4 point s

User access ( via a sniffed password, for exam ple) .

1 point

At t ack very unlikely t o succeed ( Wiz in 2002, for exam ple) .

The last exam ple, 1 point for Wiz, int roduces a really im port ant point when calculat ing severit y, and t hat is t he effect of t im e. This is known as t he let halit y curve. The at t ackers have a t erm t hey call zero day, and it references an at t ack t hat works before it is publicly known. The exploit works fine, but it is t ight ly held by a fairly sm all num ber of people who are breaking int o syst em s wit h it . This is a t im e of ext rem e let halit y, but t he num ber of uses is fairly low. Event ually, t he at t ack is discovered and published. Now t he com m unit y knows about it and so do t he at t ackers. We ent er a race condit ion—at t ackers race t o get t he exploit , learn t o use it , and at t ack our syst em s. Defenders rush t o apply pat ches, download new I DS signat ures, or im plem ent ot her count erm easures. During t his phase, t he at t ack is st ill pret t y let hal, but t he let halit y is dropping; however, t he incidence of at t ack at t em pt s goes way up. Finally, we reach t he crest of t he wave. More and m ore defenders are pat ching t heir syst em s and applying ot her count erm easures, and over t im e, t he at t ack becom es less and less dest ruct ive.

Cou n t e r m e a su r e s

What about firewalls or syst em pat ches or operat ing syst em s running from CDROMs? Count erm easures cert ainly affect severit y and can logically be divided int o syst em count erm easures and net work count erm easures. The five- point scale for syst em count erm easures is as follows:

5 point s

Modern operat ing syst em , all pat ches, added securit y such as TCP Wrappers and secure shell

3 point s

Older operat ing syst em , som e pat ches m issing

1 point

No TCP Wrappers/ allows fixed unencrypt ed passwords

The five- point scale for net work count erm easures is as follows:

5 point s

Validat ed rest rict ive firewall, only one way in or out

4 point s

Rest rict ive firewall, som e ext ernal connect ions ( m odem s, I SDN)

2 point s

Perm issive firewall ( The key quest ion is t his: " Does t he firewall allow t he at t ack t hrough?" )

Ca lcu la t in g Se ve r it y Analyst s t rained in t he GI AC approach t o int rusion det ect ion use t he following form ula t o calculat e severit y:

(Criticality + Lethality) - (System + Net Countermeasures) = Severity

Take a look at a couple exam ples. These are t aken from t he pract ical proj ect required t o achieve GI AC I nt rusion Analyst cert ificat ion. To put t he exam ples in cont ext , t he ent ire analysis process is shown, even t hough t he current focus is on severit y. The approach described here helps reinforce t hat at t acks vary in severit y. This discussion exam ines som e of t he fact ors t hat affect severit y. You can cit e t hese fact ors t o help ot hers underst and when t hey ask, " What is it about ? This at t ack t hat has you spun up?" Having a m et hod t o calculat e severit y can be handy when t he handler is in t he sit uat ion of having t o t riage, or choose how t o deploy finit e defensive asset s. To t he syst em owner, his syst em is t he m ost im port ant one in t he world ( m uch like everyone's own child is t he cut est kid) . You can use a

severit y- grading t echnique like t his one t o explain why you applied defensive asset s t o one owner's syst em rat her t han t o som eone else's. Sca n n in g for Tr oj a n s This first exam ple com es from a t race t hat David Leaphart select ed for use in his pract ical. To help get you st art ed, t he first t race is saying t hat on March 24 at 1: 54 A.M. source host com put er 24.3.57.38 connect ed from source port 11111 t o dest inat ion host com put er 24.3.21.199 on dest inat ion port TCP 12345:

Mar 24 01:54:58 cc1014244-a kernel: securityalert: tcp if=ef0 24.3.57.38:11111 to 24.3.21.199 on unserved port 12345 Mar 24 03:14:13 cc1014244-a kernel: securityalert: tcp if=ef0 171.214.113.228:2766 to 24.3.21.199 on unserved port 1243 Mar 24 04:45:01 cc1014244-a kernel: securityalert: tcp if=ef0 208.61.109.243:3578 to 24.3.21.199 on unserved port 1243 Mar 24 04:45:06 cc1014244-a kernel: securityalert: tcp if=ef0 208.61.109.243:3832 to 24.3.21.199 on unserved port 27347 Mar 24 05:40:42 cc1014244-a kernel: securityalert: udp if=ef0 24.24.100.172:2147 to 24.3.21.199 on unserved port 137 Mar 24 14:56:08 cc1014244-a kernel: securityalert: udp if=ef0 63.17.79.40:4294 to 24.3.21.199 on unserved port 137 Mar 24 17:20:44 cc1014244-a kernel: securityalert: tcp if=ef0 62.6.100.45:1828 to 24.3.21.199 on unserved port 27374 Mar 24 20:50:47 cc1014244-a kernel: securityalert: tcp if=ef0 194.27.62.179:4857 to 24.3.21.199 on unserved port 27374

from from from from from from from from

An a lysis

The following quest ions prove very useful for det erm ining t he severit y of any int rusion. Here t hey have been applied t o t he t race preceding ident ified: z

Evidence of act ive t arget ing? Yes. The t raffic from t he source is det ect ed at t he host 's int erface.

z

I dent ify t he hist ory? No. Previous t raffic from t he source address was not ed in t he det ect report .

z

I dent ify t he t echnique? TCP and UDP packet s were direct ed at a specific host . The SYN packet s were direct ed at TCP port s 12345, 1243, 27347, and 27374. The UDP t raffic was direct ed at UDP port 137. The sources are hoping for a SYN- ACK, or no response in t he case of UDP. The port scan is com ing from different sources over a num ber of hours. All t he source addresses are act ive on t he I nt ernet and do not appear t o have been spoofed.

z

Evidence of int ent ? This det ect is a port scan of t he vict im looking for various vulnerabilit ies. These can be sum m arized as follows:

Port 12345

Net bus and also t he TrendMicro list ening port

Port 1243

SubSeven and Backdoor- G Troj ans

Port 27374

SubSeven 2.0

Port 27347

Possibly a t yping error for port 27374

Port 137

Net BI OS

The analyst needs t o check t he vict im for evidence of Troj ans and ensure t hat Net BI OS is not a problem . z

I dent ify host ile individuals and groups? Based on Whois, t hese source addresses cam e from various locales. They appear t o be unrelat ed bot h in geography and t im e. The last address is of a lit t le m ore concern, however, because it originat es in Turkey. These scans appear t o be host ile, but t he vict im seem s t o be rebuffing t he scans.

Se ve r it y

I would assess t he severit y of t his breach as follows: z

Crit icalit y. This is a 2, presum ing t his is not a crit ical server.

z

Let halit y. This is a 4, because t hese exploit s can be dam aging.

z

Count erm easures. This is a 5, assum ing t hat t he OS is fully pat ched.

z

Net count erm easures. There doesn't seem t o be a firewall, so t his is a 0.

H ost Sca n Aga in st FTP Consider one m ore exam ple. Eric Brock subm it t ed Table 16.1. He used a FireWall1 firewall t o collect t he inform at ion he used for his pract ical.

Ta ble 1 6 .1 . Ex a m ple of D a t a Ga t h e r e d on a H ost Sca n Aga inst FTP

ID

Date

Tim e

Sou r ce I P

Sou r ce Por t

D e st I P

D e st Por t P

661530 21Feb2000 9: 09: 24 195.243.30.140 4858

10.10.1.1

FTP

TC

661531 21Feb2000 9: 09: 24 195.243.30.140 4857

10.10.1.0

FTP

TC

661532 21Feb2000 9: 09: 24 195.243.30.140 4860

10.10.1.3

FTP

TC

661533 21Feb2000 9: 09: 24 195.243.30.140 4859

10.10.1.2

FTP

TC

…

…

…

…

…

…

…

…

661632 21Feb2000 9: 09: 25 195.243.30.140 1144

10.10.1.252 FTP

TC

661633 21Feb2000 9: 09: 25 195.243.30.140 1145

10.10.1.253 FTP

TC

661634 21Feb2000 9: 09: 25 195.243.30.140 1146

10.10.1.254 FTP

TC

An a lysis

So as we analyze t he at t ack, we want t o begin wit h t he fact t he packet s cam e t o our DMZ; you could call t his act ive t arget ing. I t is im port ant t o det erm ine t he hist ory. I n t he list below we consider it only from our DMZ's perspect ive, but by using Dshield ( ht t p: / / www.dshield.org/ ipinfo.php) we can also look at t he hist ory of t he source I P address at ot her sit es. We describe t he t echnique t hat was used and t hen m ake are best assessm ent as t o t he purpose of t he packet s, t he int ent , t he reason we saw t hese packet s, and begin t o m ake our final analysis conclusions. z

Exist ence. Som eone claim ing t o be I P address 195.243.30.140 is visit ing us.

z

Hist ory. There is no hist ory of t his address visit ing our net work.

z

z

z

z

Techniques. The visit or is sending one FTP packet t o each address in our subnet . They are being sent ext rem ely fast . I nt ent . The visit or is at t em pt ing t o find host s on our net work t hat will respond on t he FTP port . Target ing. Our ent ire net work is being t arget ed, but no specific servers are being t arget ed. Analysis. This visit or is perform ing a scan of our net work, looking for ft p servers. The visit or could be planning a denial- of- service at t ack against an ft p

server, or he could be looking for an anonym ous ft p server t o see what he can download from it , or t o see what he can upload t o it . Se ve r it y

Severit y is m ade up of a num ber of dim ensions, t he crit icalit y of t he t arget , how let hal t he at t ack is, and any syst em or net work count erm easures t hat m ight m it igat e t he at t ack. z

Crit icalit y. This is a 3, because no specific servers are t arget ed.

z

Let halit y. This is a 4, because t here are m any known ft p vulnerabilit ies.

z

z

z

Syst em count erm easures. This is a 2, because all operat ing syst em s are running t he lat est pat ches, but som e are list ening on t he ft p port . Net work count erm easures. This is a 4, because t he firewall blocks all incom ing ft p. Severit y score. This severit y score is 1. The form ula is t his:

Severity = (Criticality + Lethality) – (System Countermeasures + Network Countermeasures)

Se n sor Pla ce m e n t A net work- based int rusion- det ect ion syst em isn't going t o work unless t here is a sensor. I t will not work opt im ally if t he sensor is not placed correct ly. Generally, som ewhere in t he vicinit y of t he firewall is a good locat ion for t he sensor.

Ou t side Fir e w a ll Usually, int rusion- det ect ion sensors are placed out side t he firewall in t he DMZ ( as shown in Figure 16.4) . This allows t he sensor t o see all at t acks com ing in from t he I nt ernet . However, if t he at t ack is TCP and t he firewall, or filt ering rout er, blocks t he at t ack, t he int rusion- det ect ion syst em m ight not be able t o det ect t he at t ack. Many at t acks can be det ect ed only by m at ching a st ring signat ure. The st ring is not sent unless t he TCP t hree- way handshake is com plet ed. Figu r e 1 6 .4 . A se n sor , or e ve nt de t e ct or , is u se d t o in st r u m e n t t h e D M Z.

Alt hough som e at t acks cannot be det ect ed by a sensor out side t he firewall, t his is t he best sensor locat ion t o det ect at t acks. The benefit t o t he sit e is t hat analyst s can see t he kinds of at t acks t o which t heir sit e and firewall are exposed. One of t he reviewers of t he book put s it t his way: " Out side t he firewall is at t ack det ect ion, and inside it is int rusion det ect ion." Well put ! During lat e 1997 and early 1998, a large num ber of sit es det ect ed at t em pt s against t he port m apper port ( TCP/ UDP 111) . Sit es wit h act ive port m appers are likely locat ions for rpc.st at d. I ran a vulnerabilit y scanner int ernally at t wo locat ions t o see whet her any risk exist ed. The scan t urned up m ore t han 50 syst em s t hat would answer an rpcinfo –p request ( which m eans an unsecured port m apper) and furt her analysis showed t hat t hey were running st at d. The firewall at bot h locat ions blocked t he at t acks, bot h via port m apper, and any at t em pt t o direct ly access st at d. Having inform at ion t hat sit es I was concerned wit h prot ect ing were under a concert ed at t ack and t hat t here was an int ernal exposure redoubled m y effort s in t he never- ending bat t le t o get t hose port m appers secured and see whet her pat ches were available from vendors for st at d. For m ore inform at ion, refer t o www.cert .org/ advisories/ CA97.26.st at d.ht m l. DMZ ( dem ilit arized zone) is t he area bet ween an I SP and t he out erm ost firewall int erface.

Se n sor s I n side Fir e w a ll A school of t hought says t hat sensors should be placed inside firewalls. Several reasons com pel t his placem ent . I f at t ackers can find t he sensor, t hey m ight at t ack it so t hat t here is less chance of t heir act ivit ies being audit ed. Syst em s inside firewalls present less vulnerabilit y t han syst em s out side firewalls. I f t he sensor is inside t he firewall and exposed t o less noise, it m ight generat e fewer false posit ives. Also, inside t he firewall, you can det ect whet her a firewall is m isconfigured ( if at t acks get t hrough t hat are supposed t o be st opped, for exam ple) . I t is cert ainly t rue t hat well- configured firewalls st op m ost low - end exploit at t em pt s. I t is also t rue t hat far t oo m uch at t ent ion is devot ed t o det ect ion and analysis of t hese low- end at t acks. Bot h I n side a n d Ou t side Fir e w a ll More is bet t er. Best of bot h worlds. You have heard bot h of t hese slogans. For m e, t hey are m ore t han m ere slogans. I deploy sensors on bot h sides of t he firewall. I f your organizat ion can afford a sensor bot h inside and out side t he firewall, t his has cert ain advant ages, such as: z

You never have t o guess whet her an at t ack penet rat ed a firewall.

z

You m ight be able t o det ect insider, or int ernal, at t acks.

z

You m ight be able t o det ect m isconfigured syst em s t hat can't get t hrough t he firewall so t hat you can help t he syst em adm inist rat or.

I f your organizat ion is using an expensive I DS solut ion, t his is not wort h t he cost and effort . I f you do deploy dual sensors, t he sensor on t he inside of t he firewall is t he one t o set up t o page you in an em ergency.

M iscon figu r e d Syst e m s I nt rusion- det ect ion syst em s and t heir analyst s should be able t o t roubleshoot t he net work. When I was involved in deploying Shadow, we usually spent t he first week or t wo helping t he sit e fix problem s wit h t he net work. This is j ust as t rue t oday. Below are som e of t he com m on problem s: z z

localhost 127.0.0.1 or 127.0.0.2 broadcast ing t o an int ernal subnet . Misconfigured DNS files. These read from right t o left ; so if your sit e's net work I D is 172.20.0.0/ 24 and you det ect a host ( 172.20.30.40) doing a broadcast t o 255.30.20.172, t hat could be a

clue t hat som eone didn't get t he word t hat dom ain files read right t o left . z

z

I ncorrect subnet m ask. Broadcast t o 172.20.255.255 rat her t han t o 172.20.30.255. Backdoors. When you see a packet com ing from t he I nt ernet t o 172.20.30.255 ( using t he net work I D from t he preceding exam ple) , t here is a pret t y good chance your net work has sprung a leak—t hat is, a packet should not be com ing from you, t o you, out side your firewall.

Addit ion a l Se n sor Loca t ion s The m ost com m on place for a sensor is out side t he firewall, but it is cert ainly not t he only place t hat benefit s an organizat ion. Many int rusion- det ect ion syst em s can be used t o support t he organizat ion in a variet y of addit ional locat ions, including t he following: z

z z

z

Part ner net works, t o which you have direct connect ions t o cust om ers and suppliers oft en inside your firewall. High- value locat ions, such as research or account ing net works. Net works wit h a large num ber of t ransient em ployees ( consult ant s and/ or t em ps, for exam ple) . Subnet s t hat appear t o be t arget ed by out siders, or t hat have shown indicat ions of int rusions or ot her irregularit ies.

A final issue in sensor placem ent is what t he sensor is connect ed t o. Net works t oday operat e alm ost exclusively on sw it ched VLAN environm ent s. Sensors can operat e in t hese environm ent s. I f t he swit ches' spanning port s are not configured properly, however, int rusion det ect ion is all but im possible. One t hing t o be aware of is t hat spanning put s a load on t he swit ch. I f a sensor is t o be operat ed in a swit ched net work, t he im plem ent at ion m ust be t est ed. TCP is a duplex prot ocol, and t he analyst should ensure t hat t he sensor is receiving bot h t he source and dest inat ion side of t he conversat ion. The sensor should also be t est ed t o ensure t hat it sends dat a reliably from t he swit ched locat ion. I t m ight be necessary t o configure t he sensor wit h t wo int erface cards. The first can m onit or in prom iscuous m ode ( list ening t o all packet s regardless of whet her t hey are addressed t o t he sensor) at t ached t o a spanning port . The second int erface would be placed on a separat e VLAN t o com m unicat e wit h t he analysis st at ion. Of course, t hrowing m oney at t he problem is always a handy t rick in int rusion det ect ion. I f you are having load and configurat ion problem s, here are a couple of opt ions:

z

z

z

Consider a net work t ap. These are connect ed direct ly t o t he m edia and allow t he sensor t o see t he dat a t hat passes by t he t ap. TopLayer, ht t p: / / www.t oplayer.com / , has a swit ch designed t o copy dat a from t he net work t o an I DS. Cisco Cat alyst 6000 swit ches can support an opt ional Policy Feat ure Card t hat allows you t o cont rol t he dat a copied t o t he I DS in about t he sam e way t he TopLayer does.

Pu sh / Pu ll Now t hat you have det erm ined where you want t o place your sensor, how will you ext ract t he dat a from it ? The preferred behavior, at least when you first deploy a sensor or event generat or, is t o push event s t o t he analysis syst em as t hey occur. When t he sensor det ect s an event , it creat es a packet wit h t he pert inent dat a and shoot s it t o t he analysis st at ion. An obvious prot ocol for t his would be som et hing like an SNMP t rap. Most com m ercial product s have t heir own propriet ary prot ocol for com m unicat ions bet ween t he sensor and analysis st at ion. The num ber- one feat ure pot ent ial cust om ers look for when t hey com pare int rusion- det ect ion syst em s is " real- t im e" response.

Pu sh y I n t r u sion - D e t e ct ion Syst e m s One of t he m ore int erest ing selling point s for int rusion- det ect ion syst em s is how obnoxious t hey can behave. I t seem s like a good idea when looking for a syst em t hat t he I DS will beep t he console, send us em ail, page us, or call our cell phones. I t usually t akes only a couple weeks t o t urn off t hese handy real- t im e not ificat ion feat ures. Even t he m ost dedicat ed analyst will accept only so m any false alarm s at t hree o'clock in t he m orning. Real- t im e is not possible unt il t he int rusion- det ect ion capabilit y exist s in t he net work swit ch fabric and com put er syst em operat ing syst em and program s t hem selves. Even so, prospect ive cust om ers of int rusion- det ect ion syst em s want t he event - det ect ion inform at ion available t o t hem as quickly as possible, and t hat m akes a whole lot of sense. Cert ainly t hen, push is t he correct archit ect ure for net work- based int rusion det ect ion, right ? Push- based archit ect ures have one very severe flaw. I f t heir behavior is such t hat t hey generat e a packet in response t o a det ect , and if t he sensor can be observed, it is fairly easy t o det erm ine how it is configured. Over t im e, t his would allow an at t acker t o det erm ine what t he sensor ignores. This kind of effort and pat ience is unlikely wit h low- end script - kiddie at t ackers, but alm ost guarant eed behavior from t he high end, such as high- value econom ic espionage. The obvious solut ion t o t his problem is t o push out t he event s on a regular basis as a st ream . This gives t he

sam e, j ust a lit t le lat er t han real- t im e response, capabilit y and m asks what t he sensor det ect s. I f t here are no det ect s, t he st ream is j ust filled wit h encrypt ed null charact ers. Figure 16.5 shows t he differences in archit ect ure bet ween push and pull syst em s. On t he whole, push is t he bet t er archit ect ure for int rusion det ect ion. One of t he best applicat ions for pull is a covert sensor, which can be em ployed in an invest igat ion. I t can be focused on a part icular com put er syst em . I t can also j ust passively m onit or com m unicat ions unt il a key phrase occurs, and t hen it can be used t o capt ure t he com m unicat ion st ream . Most of t he sniffers deployed by hackers t o collect user I Ds and passwords are pull- based syst em s. They collect dat a unt il t he collect ed dat a is ret rieved. Figu r e 1 6 .5 . Pu sh or pu ll?

An a lyst Con sole So, you have det erm ined where t o place your sensors and have select ed bet ween push, pull, or bot h paradigm s t o acquire t he EOI inform at ion. Now you can finally get t o work. The int rusion- det ect ion analyst does her work at t he analyst console. I f an elect ion was won wit h t he m ant ra, " I t 's t he econom y, st upid," som eone bet t er t ell t he int rusion- det ect ion vendors t hat , " I t 's t he console, st upid." An organizat ion t ypically looks for t he following fact ors when shopping for an I DS: z

Real- t im e

z

Aut om at ed response capabilit y

z

Det ect s everyt hing ( no false negat ives)

z

Runs on Windows XP/ UNI X/ Com m odore 64 ( what ever t he organizat ion uses)

That get s t he box in t he door, but will it st ay t urned on? I have visit ed several sit es t hat deployed com m ercial int rusion- det ect ion syst em s very early in t he gam e, and alt hough t hey are st ill connect ed t o t he net work, t he console has a t hin layer of dust on it s keyboard. Aft er t he organizat ion has been using t he syst em for several m ont hs, t he feat ure set t ends t o be as follows: z

Fast er console

z

Bet t er false posit ive m anagem ent

z

Display filt ers

z

Mark event s t hat have already been analyzed

z

Drill down

z

Correlat ion

z

Bet t er report ing

Most m aj or com m ercial I DS syst em consoles were so bad t hat t he Depart m ent of Defense funded a num ber of alt ernat e designs. Several of t hese are now hit t ing t he m arket as product s in t he Ent erprise Securit y Console m arket . Most organizat ions can't afford t o develop alt ernat ive int erfaces; so if you are in t he m arket for an I DS, t his list m ight help you select one you can act ually use. The following sect ions explore t he console fact ors in great er det ail. Fa st e r Con sole The hum an m ind is a t ragic t hing t o wast e, but t hat is exact ly what happens when we put t rained int rusion analyst s' m inds in a wait st at e. Here is what happens: The analyst has a det ect , he st art s t o gat her m ore inform at ion, he wait s for t he window t o com e up, he wait s som e m ore, and suddenly can't rem em ber what he was doing. I was working wit h t he sales engineer of an I DS com pany recent ly and t ried t o point out t hat t he int erface was very slow. His answer of course was t o buy a fast er com put er. ( This was a t win 1.2Ghz Pent ium I V wit h a gigabyt e of RAM, which was st ill fairly current for January 2002.) One sim ple t echnique for im proving t he console perform ance is for t he syst em t o always query t he inform at ion for any high- priorit y at t ack and have it canned and ready for t he m om ent t he analyst clicks on it . This way, t he com put er can wait for t he analyst , rat her t han t he ot her way around. Fa lse Posit ive M a n a ge m e n t False posit ives happen. Som et im es we can't filt er t hem out wit hout incurring false

negat ives, so we m ust ask: What we can do t o m anage t hem ? The Code Red web at t acks serve as a good exam ple. I f we writ e a filt er t hat dam pens probes t o port 80 ( and m ost of us did) , we st and t he risk of a m assive false negat ive. I f we don't use such a filt er, we will cause a large num ber of false posit ives ( false posit ive in t he sense t hat if we are not running a vulnerable version of I I S, we don't need t o be concerned wit h Code Red) . Because Code Red is a Windows problem , we could get part of t he way t owards handling t his problem wit h a bet t er filt er. I f our filt er language support s it , we could put in basic passive fingerprint ing inform at ion for Windows int o our filt er. For inst ance, a Windows syst em default s t o a TTL of 128 and TCP window sizes bet w een 5,000 and 9,000 for Windows NT and bet ween 17,000 and 19,000 for Windows 2000; so if we see a TTL of great er t han 128 and a window size t hat is not wit hin spec, perhaps we could afford not t o display t he det ect . We st ill collect it , but we do not bot her t he analyst wit h it . When t he analyst select s any event in t he pot ent ial false posit ive class, t he console should display t he regular norm al inform at ion t hat it always does, but also t he addit ional dat a t o enable t he analyst t o m ake t he det erm inat ion.

Re spon sibilit y for Fa lse Posit ive I DS vendors' feet need t o be held t o t he fire for bet t er false posit ive m anagem ent . The Snort ruleset is get t ing bet t er and bet t er about providing inform at ion in t he help file t hat t ells an analyst whet her t here are possible false posit ives and what t hey are. But t his is not good enough. Vendors m ust be diligent in reducing t hem , because false posit ives are t he biggest hurdle t o successful incident m anagem ent . Vendors should fix filt ers t hat cause t oo m any false posit ives, m ake sure t hat filt ers vulnerable t o t hem are t unable, and delet e filt ers t hat are useless and cause t oo m any false posit ives. I f not hing else, t hey m ust carefully docum ent exact ly t he t raffic pat t ern t riggering t he filt ers t o report false posit ives. D ispla y Filt e r s The false posit ive m anagem ent t echnique j ust discussed is used on som e com m ercial I DS syst em s and should be considered a m inim um accept able capabilit y. To reach a goal of det ect ing as m any event s of int erest as possible, you have t o accept som e false posit ives. Display filt ers are one way t o m anage t hese. This is not a new idea; net work analysis t ools, such as NAI 's Sniffer, have always had bot h collect ion and display filt ers. M a r k a s An a lyze d Unless you are a second- level ( supervisor, t rainer, or regional) int rusion analyst , life is t oo short t o inspect event s t hat have already been m anually analyzed. Aft er

an analyst has inspect ed an event , it should be m arked as done. This is not rocket science. Aft er all, t he web browsers we all use m ark t he URLs we have already visit ed. I deally, t his would be m ore like t he edit ing funct ions on m odern word processors such as Microsoft Word—t he event get s a t ag wit h t he dat e and t im e it was analyzed and t he usernam e of t he analyst , and whet her it was rej ect ed as a false posit ive or accept ed and report ed. D r ill D ow n We cert ainly wouldn't want t o provide users an int erface t hat int im idat es t hem ! When an organizat ion first st art s perform ing int rusion det ect ion, it m ight be quit e happy wit h t he syst em displaying a GUI int erface wit h a pict ure, t he nam e of t he at t ack, dat e, t im e, and source and dest inat ion I Ps. The happiness oft en ends when t he organizat ion finds out t hat it has report ed a false posit ive. At t his point , t he analyst st art s t o desire t o see t he whole enchilada and it should be available wit h one m ouse click. Drill down is a very powerful approach. Analyst s get t o work wit h big- pict ure dat a, and t hen as soon as t hey want m ore det ail, t hey j ust click. The analyst should not have t o leave t he int erface he is using—t hat discourages research. Analyst s cert ainly should not have t o ent er a separat e program t o get t o t he dat a—t hat is inexcusable. Drill down is not possible unless t he dat a is collect ed ( and it cert ainly ought t o include t he packet headers) . No analyst should have t o report a det ect he can't verify! Cor r e la t ion Every analyst has seen a det ect and scrat ched his head saying, " Haven't I seen t hat I P before?" I nt rusion analyst s at hot sit es ( sit es at t acked fairly oft en) frequent ly det ect and report bet ween 15 and 60 event s per day. Aft er a couple of weeks, t hat is a lot of I P addresses t o keep t rack of m anually. I t also is not hard for t he analysis console t o keep a list of sit es t hat have been report ed and color t hose I P addresses appropriat ely. Be t t e r Re por t ing Two kinds of report s m ake up t he bread and but t er of t he int rusion analyst : event det ect ion report s and sum m ary report s. Event report s provide low - level det ailed inform at ion about det ect s. Sum m ary report s help t he analyst t o see t he t rends of at t acks over t im e and t he m anager t o underst and where t he m oney is going. Ev e n t - D e t e ct ion Re por t s

Event - det ect ion report s are eit her done event by event or as a daily sum m ary report . They are usually sent by elect ronic m ail. The I DS should support flexibilit y in addressing and offer PGP encrypt ion of t he report . The report s m ight be sent t o groups t hat specialize in collect ing and analyzing t his inform at ion such as

I ncident s.org or Securit yFocus or t he organizat ion's CI RT or FI RST t eam , t he organizat ion's securit y st aff. I f you are shunning t he at t acker or plan t o t ake act ion, anot her powerful t echnique is t o file t he report as a m em o t o record. For every det ect displayed on t he console, t he analyst should have t he opport unit y t o report wit h a single m ouse select ion accept ing t he det ect . The syst em should t hen const ruct a report , which t he analyst reviews and annot at es before sending. I f you are shopping for an int rusion- det ect ion syst em or Ent erprise Securit y Console, sit down at t he console and see how long it t akes you t o collect t he inform at ion needed t o report an event and t o send it via em ail ( or ot her form at such as XML) t o a CI RT or FI RST t eam . I f you can't access raw or support ing dat a, t ake your hands off t he keyboard and walk away from t he syst em . I f it t akes m ore t han five t o seven m inut es and your organizat ion int ends t o report event s, keep shopping. I f you can collect t he inform at ion including raw or support ing dat a and send it in wit hin t wo m inut es, please send m e em ail t elling m e about t he product so I can get one t oo. W e e k ly/ M on t h ly Su m m a r y Re por t s

Managem ent oft en want s t o st ay abreast of int rusion det ect s direct ed against t he sit es for which t hey are responsible. Event - by- event or even daily report ing m ight prove t oo t im e consum ing, however, and doesn't help t hem see t he big pict ure. Weekly or m ont hly report s are a solut ion t o t his problem . I n general, t he higher level t he m anager, t he less frequent ly she should be sent report s.

H ost - or N e t w or k - Ba se d I n t r u sion D e t e ct ion The m ore inform at ion we can provide t he analyst , t he bet t er chance she has of solving t he difficult problem s in int rusion det ect ion. What is t he best source of t his inform at ion, host based or net work based? I f you read t he lit erat ure on host - based int rusion- det ect ion product s, you m ight conclude t hat host based is a bet t er approach. And, of course, if you read t he lit erat ure of com panies t hat are prim arily net work based, t heirs is t he preferred approach. Obviously, you want bot h capabilit ies, preferably int egrat ed, for your organizat ion. Perhaps t he best way t o consider t he st rengt hs of t he t wo approaches is t o describe t he m inim um reasonable int rusion- det ect ion capabilit y for a m oderat ely sized organizat ion connect ed t o t he I nt ernet , such as shown in Figure 16.6. Figu r e 1 6 .6 . A com m on a r ch it e ct u r e for a m ode r a t e ly siz e d or ga n iza t ion .

The sensor out side t he firewall is posit ioned t o det ect at t acks t hat originat e from t he I nt ernet . DNS, em ail, and web servers are t he t arget for about a t hird of all at t acks direct ed against a sit e. These syst em s have t o be able t o int eract wit h I nt ernet syst em s and can only be part ially screened. Because t hey face high overall risk, t hey should have host - based int rusion- det ect ion soft ware t hat report s t o t he analyst console as well. This shows t he need for bot h capabilit ies, host and net work based, even for sm aller organizat ions. As t he size and value of t he organizat ion increases, t he im port ance of addit ional count erm easures increases as well. This m inim um capabilit y does not address t he insider t hreat . Much of t he lit erat ure for ( prim arily) host - based solut ions st resses t he insider at t ack problem . I keep seeing st udies and st at ist ics t hat st at e t he m aj orit y of int rusions are caused by insiders. This is beginning t o change and m ost expert s agree t hat t he m aj orit y of at t acks com e from t he I nt ernet . Malicious code has becom e a huge problem , however, and in som e sense Troj ans and inform at ion- gat hering viruses can be t hought of as insiders aft er t hey are in your syst em s. I f insider at t acks are a prim ary concern for your organizat ion, addit ional m easures t o achieve a m inim um capabilit y are required, such as t he following: z

z

z

Use t aps or spanning port s on net work swit ches so t hat you are not blind on t he inside. Configure t he filt ers on your DMZ sensor so t hat t hey do not ignore your int ernal syst em s.You m ust keep t abs on out going t raffic as m uch as incom ing. This is especially t rue because m alicious code has becom e such a m aj or problem . Configure t he filt ers on your border rout er or firewall t o allow only out bound t raffic if t he addresses correspond t o your assigned I nt ernet addresses. This is called egress filt ering and t here is a how- t o paper available at t he I ncident s.org web sit e ( ht t p: / / www.incident s.org/ defend/ egress.php) .

z

z

z

z

z

Deploy net work- based sensors at high- value locat ions such as research and account ing. Deploy honeypot syst em s at j uicy locat ions wit h files t hat appear t o be anyt hing you t hink insider at t ackers m ight be t rying t o st eal. Place addit ional sensors from t im e t o t im e on user net works as a random spot check. At t he very least , you should deploy host - based int rusion- det ect ion code on all server syst em s as well as corporat e officers and ot her key personnel. Many personal firewalls are available for less t han $75 a st at ion, and t hey are easy t o deploy ( Tiny, ZoneAlarm , BlackI ce, and Sym ant ec I nt ernet Securit y, for exam ple) . Est ablish a reward syst em for t hose who report on em ployees who m isuse or st eal from t he organizat ion.

Su m m a r y Very oft en, t he feat ures t hat seem m ost desirable when searching for an int rusiondet ect ion syst em don't prove t o be all t hat im port ant in act ual use. The first one t o go is usually t he capabilit y t o send alert s t o t he analyst 's pager. For various reasons, int rusion- det ect ion syst em s cannot even look at every possible event . Why? This chapt er ident ified a few possible reasons: The event happened on anot her net work. The I DS is dead. The I DS has no underst anding of t he prot ocol. Perhaps t he I DS has reached it s m axim um bandwidt h lim it and dropped t he packet . Furt her, t he net work- based I DS is lim it ed t o t he capabilit ies of t he spanning port on a swit ch, and encrypt ed packet s prevent I DS ident ificat ion. An analyst get s bet t er result s from an int rusion- det ect ion syst em if he underst ands what he is searching for and t unes t he I DS t o find it , as opposed t o let t ing t he I DS t ell t he analyst what t o look for. I f you have only one sensor, place it out side your firewall. When you have evidence t hat your sit e is under a t arget ed at t ack, and t hat t he at t acker knows t he t ype of operat ing syst em s you have and is t arget ing t hem accurat ely, t ake addit ional count erm easures swift ly. I f possible, im plem ent a balanced int rusion- det ect ion capabilit y wit h bot h net work and host - based solut ions.

Ch a pt e r 1 7 . Or ga n iza t ion a l I ssu e s

What does risk m anagem ent have t o do wit h int rusion det ect ion? Every organizat ion eit her consciously or subconsciously m akes decisions about risk. Obviously, we decide how m uch risk we are willing t o accept ourselves. The dist ribut ed denial- of- service at t acks t hat becam e widely know n in February 2000 and Code Red at t acks in 2001 dem onst rat e clearly t hat we also decide how m uch risk we are willing t o accept on ot hers' behalf. The securit y of m y sit e depends, at least in part , on t he securit y of your sit e. This chapt er lays t he groundwork t hat will enable you t o present a cogent argum ent t o your m anagem ent t hat int rusion det ect ion is one t ool for m anaging risk, or part of an overall securit y archit ect ure. The highest and best purpose of a net work int rusion- det ect ion syst em is t o ident ify t he at t acks being direct ed against our perim et er defenses so t hat we can ensure our syst em s are hardened t o wit hst and t hese at t acks. I n ot her words, int rusion det ect ion m ust serve as inst rum ent at ion t hat enables us t o define t he m et rics we need t o m anage risk int elligent ly. This chapt er also t ies riskm anagem ent t echniques and concept s direct ly t o int rusion det ect ion.

Or ga n iza t ion a l Se cu r it y M ode l To m anage risk, we need a m odel, a way of describing t he problem and what needs t o be done from a process st andpoint so t hat we can get our arm s around t he problem . A sim ple exam ple of a m odel is t he Top Twent y list . You can find one at www.sans.org/ t op20.ht m . I t list s t he t op t went y vulnerabilit ies t hat at t ackers exploit and how t o fix t hem . Every m aj or vulnerabilit y scanner looks for evidence of t hese. This is a sim ple m odel, list ing t he t went y vulnerabilit ies m ost oft en exploit ed. Make sure t here are t ools t o find t hese vulnerabilit ies, and describe t he fixes so t hat all users can repair t heir syst em s. I f a significant num ber of people do t his, at t ackers will have a m uch harder t im e com prom ising syst em s, and everyone's risk is reduced. Alan Paller, a good friend of m ine, creat ed t his m odel. Alan Paller is t he Direct or of Research for t he Syst em Adm inist rat ion, Net working, and Securit y ( SANS) I nst it ut e, and he developed anot her m ore com plex m odel

while on an int ernat ional flight wit h som e of t he t op securit y m inds in t he world. During t he long flight t o Aust ralia, he cont inued t o int erview and quest ion t hese individuals t o develop a com prehensive securit y m odel. While working wit h t his m odel, I have been im pressed wit h t he result s it gives aft er you t ake t he t im e t o im plem ent it . As I reflect on t he effort s and challenges of direct ing t he st art up effort t hat creat ed t he Global I nform at ion Assurance Cert ificat ion ( GI AC) cert ificat ion and SANS I m m ersion t raining t racks, I am deeply t hankful t o have had a m odel like t his t o use. Aft er t went y years of governm ent service, adj ust ing t o t he speed we have t o m ove at m akes it hard t o rem em ber which way is up som e days. What t o do? When I worked for t he Ballist ic Missile Defense Organizat ion ( BMDO) , I used t his securit y m odel t o help m e sort out t he m any cont radict ory priorit ies. I n t he governm ent , everyt hing is so ponderous t hat you need a roadm ap t o rem em ber what you are t rying t o do. Wit h SANS and t he GI AC, everyt hing is " pract ice what you preach." I f we t each it , we do it . So, I am t rying t o im plem ent t he sam e m odel in a st art up world where everyt hing changes everyday. I did not develop t his m odel; Alan Paller, Gene Schult z, Mat t Bishop, and Hal Pom eranz did, but I have used it in t he past and it has worked for m e. I offer it t o you in t he hope t hat it helps you as well. As I describe it here, I will put an I D slant on t he m odel, but you cert ainly can apply it in a m ore general way. List ing 17.1 shows t he result s of t heir work ( court esy of Mat t , Alan, Hal, and Gene) . Let 's t ake a look at it . I nst ead of t hree st eps ( det erm ine t he t op t went y vulnerabilit ies, scan or t est for t hese vulnerabilit ies on your syst em s, and fix t hese vulnerabilit ies if t hey are present ) , t his m odel has seven st eps. List ing 17.1 The Seven Most I m port ant Things t o Do I f Securit y Mat t ers 1 . Writ e t he securit y policy ( wit h business input ) . 2 . Analyze risks or ident ify indust ry pract ice for due care; analyze vulnerabilit ies. 3 . Set up a securit y infrast ruct ure. 4 . Design cont rols and writ e st andards for each t echnology. 5 . Decide which resources are available, priorit ize count erm easures, and im plem ent t he t op priorit y count erm easures you can afford. 6 . Conduct periodic review s and possibly t est s. 7 . I m plem ent int rusion det ect ion and incident response. Se cu r it y Policy

Wait ! Please don't close t his book j ust because I wrot e t he words securit y policy. From m y experience t raining analyst s and t eaching classes on int rusion det ect ion, I know t hat t he last t hing an int rusion- det ect ion analyst want s t o do is writ e a securit y policy. When I t each, if I say " policy," I can see t he eyes glaze over inst ant ly. But applying filt ers t o an I DS is kind of neat , right ? Consider t hat t he filt er rule set you upload t o a sensor is called a policy. This is t rue for m ost ot her com m ercial syst em s, and it is well nam ed because t hese filt er set s are a securit y policy. A firewall is j ust an engine t hat enforces net work policy. So let 's recalibrat e ourselves not t o t hink of securit y policy as a pile of paper t hat t ook weeks t o writ e and now sit s gat hering dust . For an int rusion- det ect ion analyst , a securit y policy is a perm ission slip, t he organizat ion's approval t o inst all dynam ic and act ive policy in securit y engines, such as firewall and int rusiondet ect ion syst em s. That 's right , policy can serve as perm ission t o do t he right t hing! At it s heart , an I DS is a m onit oring device and you should never m onit or people wit hout aut horizat ion. Policy is t he um brella t hat covers us when we execut e t he st eps t o act ually use an I DS effect ively. I n du st r y Pr a ct ice for D u e Ca r e Bot h risk and vulnerabilit ies are discussed furt her, so for right now, let 's focus on due care, or best pract ice. Act ually, I abhor t he t erm best pract ice, perhaps we can use pret t y good pract ice inst ead. Alt hough every organizat ion has pocket s of expert ise, no one group has all t he answers. As you know, t he t echnology rat e of change is so high t hat none of us can keep up across all t he subj ect areas. The best solut ion t o t his problem is t o learn what people are doing and what is working for t hem . One of t he great est j oys for m e in being affiliat ed wit h t he SANS I nst it ut e has been t he consensus proj ect s. Many of t hem are called St ep by St eps, such as Securing Windows 2000—St ep by St ep. These are not t he work of a single person, but m any com m it t ed professionals who com e t oget her on a proj ect t o share t heir knowledge wit h ot hers. Se cu r it y I n fr a st r u ct u r e Robert Peavy, t he Direct or for Securit y and Count er- I nt elligence for t he BMDO, prepared a t alk for t he Federal Com put er Securit y Conference t it led, " Securit y as a Profit Cent er—How t o Sell Prot ect ion t o Your Leadership." As m uch as anyone I have ever m et , Robert Peavy underst ood t hat securit y, good securit y, requires people. This is at least as t rue in t he int rusion- det ect ion field as any ot her securit y dom ain. I nt rusion- det ect ion analyst s are front - line t roops. They oft en feel personally responsible for any at t acks t hat penet rat e an organizat ion's defenses and com prom ise syst em s. They get burned out and t here are som e t urnover issues, especially if t hey are double- hat t ed wit h incident response as well. They need t raining t o rem ain aware of t he lat est at t acks, but t here is lim it ed high- qualit y t raining available for t hem . What does all t his m ean? I t m eans t he wise organizat ion has som e dept h for t he role of int rusion- det ect ion analyst and

t hat t akes a securit y infrast ruct ure t o accom plish. I m ple m e n t in g Pr ior it y Cou n t e r m e a su r e s As I am writ ing t onight , I have a great fear. I have run vulnerabilit y scanners at a num ber of organizat ions t hat have bot h UNI X and now an increasing num ber of Windows 2000/ XP com put ers. I am shocked by t he num ber of syst em s t hat st ill have well known vulnerabilit ies as well as t he num ber of syst em s t hat st ill have SNMP; and it has been t wo weeks since t he CERT advisory on SNMP and t he PROTOS t est kit was released t hat searched for t housands of problem s. Will t his be t he next rst at d? Since 1997, an ever- growing num ber of Sun Solaris UNI X syst em s cont inue t o be com prom ised using a buffer exploit against t he rst at daem on. Several bufferoverflow exploit s are available for DNS, so it cert ainly could happen. Last week, I scanned a UNI X syst em being placed out side a firewall. I t had t he Echo, Chargen, port m ap, and r- ut ilit ies open. I t rem inded m e of elem ent ary school when we used t o put t hose signs on our classm at es saying, " Kick Me." How do you know whet her som et hing is a priorit y count erm easure in a world where everyt hing is t he num ber- one priorit y? I f an at t acker can exploit a vulnerabilit y from t he I nt ernet as easily as a hot knife slicing t hrough but t er, you have t o decide whet her you want t o fix t he problem before or aft er t he syst em is com prom ised. I cont inue t o be ast ounded by t he num ber of organizat ions t hat do not have t im e t o do it right , but t hey do have t im e t o do it over. Pe r iodic Re vie w s Wake up! I f you are an int rusion- det ect ion analyst , do not m iss t his! I t is im perat ive t hat you review your filt er set from t im e t o t im e. When I worked on t he Shadow int rusion- det ect ion proj ect , one of t he t hings I forced m yself t o do every couple of m ont hs was t o run t he com plem ent of our filt er set against a week's wort h of dat a and m anually parse t hrough t he result s looking for anom alies. We m ust st rive t o cont inue t o enhance our filt er set s t o reduce false negat ives. I f t his m ont h's set of filt ers is picking up exact ly t he sam e at t acks as t hree m ont hs ago, t his is a bad sign. So, besides set t ing filt ers t o t rap t he t hings one norm ally ignores, how do we im prove our filt ers? The bugt raq m ailing list has proven t o be an excellent source of inform at ion about new at t acks, each of which m ight need new filt ers. Once again, if you can find anot her group doing int rusion det ect ion and st riving t o do it well, and you can exchange inform at ion, as t his is anot her excellent way t o st ay current . Conduct ing periodic reviews is a m ore general securit y principle t han j ust wat ching our filt er set , of course. The int rusion- det ect ion analyst also profit s by exam ining t he firewall filt er set on a fairly regular basis.You m ight find what I call firewall

creep. When t he firewall was first inst alled, it had a fairly t ight and orderly ruleset . As t im e goes on, however, t his business int erest and t hat new service becom e a set of except ions, or m odifiers, t o t he ruleset . As t he rules grow, it becom es harder and harder t o validat e t hem . Also, from t im e t o t im e, t he firewall adm inist rat or m ight add in a special rule " j ust for t est ing" and forget t hat it is t here. As an analyst you t hink, " No problem , we are blocking UDP port um pt y clut ch," when in fact you aren't . The real difficult y is t racking t hese changes; t hey happen when you least expect t hem and over a long period of t im e, a bit like a low and slow scan. I am st art ing t o t hink t hat ext ernal scanning services wit h dat abases, so you can t rack what has changed, are a m ust . I f you have never considered one of t hese, you m ight want t o visit ht t p: / / www.qualys.com / . I m ple m e n t in g I n cide n t H a n dlin g An exhaust ive discussion of incident handing is beyond t he scope of t his book, but I want t o t ouch on it as it relat es t o t he m odel. Have you ever been cert ified t o adm inist er CPR? How confident would you feel if you had t o adm inist er CPR 3, 6, 12 m ont hs aft er your t raining? I call t hese " gulp" m om ent s. I know I am qualified as an incident handler in som e sense, but if I haven't handled an incident in a couple of m ont hs, I really feel t he rust . What does incident handling have t o do wit h int rusion det ect ion? A lot ! The analyst is likely t o be t he one t o raise t he alarm . I n organizat ions wit h st ruct ured incident handling capabilit ies, t he analyst m ight be assigned t o provide net work inform at ion t o t he handlers. I n organizat ions wit hout t hese st ruct ured incident handling capabilit ies, t he handlers are likely t o be you and a syst em adm inist rat or or t wo. I n t he " Manual Response" sect ion of Chapt er 18, "Aut om at ed and Manual Response," read carefully and m ake not es concerning t he t hings you know you need t o do before you have t o handle a serious incident . I f you do t his, it will really help when t he gulp m om ent com es.

D e fin in g Risk What are t he scariest t hree words an int rusion analyst is likely t o hear? We can't reasonably m anage risk if we don't know what risk is. Risk occurs in t he dom ain of uncert aint y. I f t here is no uncert aint y, t here is no risk. Jum ping out of an airplane t wo m iles up wit hout a parachut e isn't risky; it is suicide. For such an act ion, t here is a nearly 1.0 probabilit y you will go splat when you hit t he ground, or an alm ost 0.0 probabilit y you will survive. However, t here is also risk t o j um ping out of perfect ly good airplanes wit h parachut es, as several skydivers discover each year. Let 's apply t his concept t o rout er prot ect ion filt ers. I n m any cases, t hese filt ers are connect ion event s—t hat is, t hey are port num ber based. I f we see a TCP connect ion at port 25, we ident ify it as sendm ail and t ake what ever act ion is

prescribed. However, any service can act ually run at any port . There is t he uncert aint y; t here is a risk t hat we will m ake t he wrong decision. Wit h t he ephem eral port s ( above 1024) , t his happens oft en. This uncert aint y, coupled wit h t he fact t hat an adverse act ion could be exploit ed ( a service we int ended t o block could penet rat e our sit e) , leads t o a risk. This is one reason m any securit y professionals t hink t hat a filt ering rout er does not serve as a firewall. An int rusion- det ect ion analyst needs t o know t he degree of uncert aint y for specific filt ers. As an exam ple, SYN flood filt ers oft en have a high degree of uncert aint y. I f an int rusion- det ect ion analyst cont inues t o report t hese, t here is t he pot ent ial for an adverse act ion. The CI RT m ight begin t o t rivialize t his analyst 's report s. Therefore, a filt er's degree of uncert aint y can result in risk t o t he analyst and t he organizat ion, especially in high- profile cases. Conversely, t he expert analyst knows t he condit ions in which a filt er is likely t o perform well and also t he condit ions t hat lead t o failure. These analyst s develop t he abilit y t o " read bet ween t he lines." Perhaps, t he sim ple issue of reput at ion doesn't grab you. The sam e problem , uncert aint y of filt ers, get s m ore int erest ing if a sit e em ploys aut om at ed response t echniques. I want t o briefly m ent ion one m ore pot ent ial adverse result of uncert aint y wit h int rusion- det ect ion filt ers. Several com m ercial I DS vendors provide list s of t heir filt ers. Som et im es, t hey rat e t heir filt ers by t heir probabilit y of producing a false posit ive and perhaps list condit ions known t o cause t he false posit ives. This is a great service t o t he analyst . What if a com pany list s som e of it s filt ers as not having any chance of a false posit ive—t hat is, t here should be no uncert aint y, t herefore t here is no risk. Then, you dig in and find several of t hese filt ers do generat e false posit ives. That realizat ion can underm ine your confidence in t he com pany. I know; it happened t o m e. I n fact , I st art ed building t est cases for t he filt ers t hat according t o t he lit erat ure had no chance of a false posit ive and found several ot her filt ers had flaws. Well t his really bugged m e. Why say it doesn't error if it does? Then, I rem em bered t hat I had been issued a brain t o keep m y heart in check. Why get m ad at t his com pany when t hey have t he m ost com plet e filt er docum ent at ion of any com m ercial I DS? So, I j ust updat ed m y copy of t he filt er docum ent at ion and sent t hem t races of m y t est cases. What do I get for m y effort ? I know a lot m ore about which det ect s t o be uncert ain about and t he condit ions likely t o cause t he filt ers t o error and generat e a false posit ive. What about t he Snort ruleset ? I t is open and can be exam ined and has been subj ect ed t o exhaust ive public review—are t hese rules uncert ain? To be sure, t here are great advant ages t o public review ( and you can bet t hat m ore t han one or t wo of t hose rules finds it s way int o ot her I DS syst em s) , but t he fact t hat it is open m eans an at t acker can be aware of it and m odify t he at t ack j ust enough t o evade t he rule. Oh yeah, t he scariest t hree words t o an int rusion- det ect ion analyst . They are when t he gruff old decision- m aker who has t o m ake a hard call looks you in t he eye and

asks, " Are you sure?"

Risk Risk happens. I t is ridiculous t o say I don't want any risk in a given sit uat ion. Rat her, we m anage risk. I heard on TV once t hat t he space shut t le oft en has backup syst em s for it s backup syst em s. A shut t le flight is an exercise in st rapping yourself t o a rocket and heading for space. Space is an environm ent where any num ber of t hings can kill you: radiat ion, heat , cold, vacuum , and finally t he reent ry. I f you approach a reent ry wit h t oo st eep an angle, t he m ist ake will crash you; and if your angle is t oo shallow, it will bounce you int o space. That is a lot of risk, which is one of t he reasons ast ronaut s get all t he free Tang t hey can drink. I f you really t hink it t hrough, t he whole process is nut s and no sane person would do it . NASA act ually has go/ no go crit eria. I f anyt hing is wrong, t hey do not go ahead wit h t he launch, even t hough t here are backup syst em s. This is j udged an unaccept able risk. Ot her risks are considered accept able, like t he bit about st rapping yourself t o a rocket . Wit h any risk, we m ust decide how we will deal wit h risk. We have t hree opt ions for dealing wit h risk: z

Accept t he risk as is.

z

Mit igat e or reduce t he risk.

z

Transfer t he risk ( insurance m odel) .

Acce pt in g t h e Risk I f we don't inst all a firewall and we connect t o t he I nt ernet , in som e sense we are as daring as t he m en and wom en who bolt t hem selves ont o rocket s; what we are doing is risky and we've chosen t o accept t hat risk. I f we have inform at ion asset s of high value and we don't do audit ing on t hese host s or use som e form of int rusion det ect ion, we are again choosing t o accept t he risk. The concept of accept ing risk is sim ple enough, but t here is anot her aspect of t his we need t o consider. The elem ent ary school bus driver who drinks a few t oo m any beers before picking up t he kids wit h his school bus is accept ing risk all right , but he is accept ing risk he does not have a right t o accept . The firewall adm inist rat or who was j ust t est ing som e service and m ist akenly left it in t he syst em m ight have caused t he organizat ion t o accept a risk t hat it would not choose t o accept . Aft er all, why did it go t hrough t he t rouble t o buy and set up a firewall? One of t he int erest ing problem s of inform at ion securit y is t hat it is quit e possible for an individual t o accept a risk for an organizat ion t hat he is not aut horized t o accept . I would like t o illust rat e t his point wit h an int rusion- det ect ion st ory. Last week, we det ect ed syst em s init iat ing file t ransfers from a sit e t hat we

m onit or. I t was j ust odd enough t hat we decided t o look int o it a bit furt her. When we exam ined t he payload of t he ft ps, it was clear each of t hese syst em s was sending a bit of inform at ion about it self. We weren't sure what t he inform at ion was unt il we saw a couple inst ances of " Preferred Cust om er." I t seem ed like it had t o be t he regist rat ion field for Microsoft Office product s. Our suspicions were quickly confirm ed. A m em ber of Hum an Resources had sent a m em o as an at t achm ent t o an em ail m essage t o all t he senior m anagers of t he organizat ion. I t was t he fact t hey were senior m anagers t hat alert ed m e t o furt her invest igat e t he ft p sessions; t hese folks didn't even read t heir own em ail! They had a secret ary screen t heir m ail, print it , and put t he im port ant m essages in t heir inbox. The em ail m essage sent by Hum an Resources was infect ed wit h a m acro virus t hat sent inform at ion out of t he organizat ion. I t apparent ly didn't do any serious harm . From an inform at ion warfare perspect ive, however, I was appalled, because it gives a clear pot ent ial infect ion vect or int o t his organizat ion, which could be exploit ed at a lat er t im e. This support em ployee, by j ust failing t o m aint ain current virus soft ware, accept ed a high degree of risk for t he ent ire organizat ion. As Jim m y Kuo, a research fellow at NAI would say, " You are only as good as your last updat e." How about one m ore exam ple? The sam e week we det ect ed m any m ore syst em s init iat ing file t ransfers t han usual from t he sam e sit e we m onit or. We found five in one day. When we pulled t he payload, we found t hey were all going t o t he sam e I P address, t he sam e user I D, and t he sam e password. They were downloading files t o t he deskt op syst em s. I n t his case, it t urned out t o be a shareware program , PKZip. Now, t his is no Troj an; t his is no sneak at t ack. A paragraph on t he shareware web sit e st at ed t hat when PKZip was inst alled it cam e wit h a bonus com ponent t hat downloaded ads. None of t he five users gave a second t hought t o what t hey were act ually doing; t hey j ust want ed PKZip. So what 's t he problem ? Well, so long as t he soft ware is j ust downloading ads, t here isn't a problem . However, keep in m ind t hat m any sit es configure t heir firewalls so t hat if a connect ion is init iat ed from t he inside, it passes t hrough t he firewall wit hout any problem s. This m eans t here are several pot ent ial at t acks from such a behavior. Tr oj a n Ve r sion

We have seen several exam ples of Troj an versions of legit im at e soft ware, such as t he Troj an I CQs and I nt ernet Relay Chat ( I RCs) . The user would not be aware t hat t he program was act ually uploading sensit ive dat a from t he syst em , or downloading t ools t hat could be used t o at t ack his organizat ion's net work from t he inside. I n t he sam e vein, what if t he advert isem ent com pany hired a m alicious individual, or an expert in econom ic espionage? Think about what he could accom plish wit h robot code t hat downloaded arbit rary files every t im e a syst em was boot ed! I f t his seem s like science fict ion, consider t he use of net bugs ( www.bugnosis.org) and spyware t hat is so com m on t oday.

M a liciou s Con n e ct ion s

There are a num ber of DNS at t acks, but t he idea in DNS cache poisoning is t o m anipulat e t he DNS syst em so t hat t he client syst em goes t o a m alicious server rat her t han t o t he act ual server. This is oft en done when a client answers a quest ion, wit hin a query. The problem is com plex; users of deskt op Windows syst em s do not generally know what connect ions t heir syst em s are m aking. I honest ly didn't know t hat soft ware program s on m y Windows syst em could connect t o t he I nt ernet wit hout m e clicking on t hem . Several years back, I bought a soft ware package, McAfee Office, prim arily t o get t he Pret t y Good Privacy ( PGP) t hat com es wit h it , but decided t o play wit h m ost of t he soft ware. One of t he program s was called GuardDog, which is a securit y program for Windows syst em s. I inst alled it , and im agine m y surprise when I boot ed m y com put er and it barked at m e, t o warn m e t hat one of t he program s on m y syst em was t rying t o connect t o t he I nt ernet . I t was Real Audio; I didn't have t he t im e t o set up m onit ors and t raps in m y hom e lab t o t rack it , so I j ust uninst alled it . Lat er, it t urned out t hey were collect ing inform at ion on users. Today, I use applicat ion- aware personal firewalls such as ZoneAlarm and Nort on I nt ernet Securit y. We have gone t hrough som e im port ant inform at ion, so let 's t ake a second t o sum m arize som e point s. I n t he preceding t wo exam ples, m acro virus and PKZip, users' deskt ops init iat ed connect ions t o t he I nt ernet wit hout t he users knowing about t he connect ions. Bot h cases have t he pot ent ial for harm t o t he organizat ion, alt hough m ercifully t he only real dam age in t hese exam ples was m y blood pressure shoot ing t hrough 200. I n bot h cases, one by inact ion, one by act ion, t he users m ake a personal decision t o accept a risk t hat affect s t he ent ire organizat ion.

Ex pa n din g Ou r Vie w of I n t r u sion D e t e ct ion Neil Johnson, a researcher and facult y m em ber at George Mason Universit y, present ed a really wonderful paper on int rusion det ect ion and recovery against wat erm arked im ages at t he SANSFI RE 2000 conference. I f you spend a lot of t im e and m oney creat ing graphics, you m ight want t o put a copyright seal on t hese graphics in som e way. There are t ools t o do t his. Then, it is possible t o use World Wide Web worm t echnology t o search t he I nt ernet looking for graphics t o see whet her your seal t urns up on som e server t hat didn't license t he graphic. Neil explained t his and dem onst rat ed bot h at t acks and t he recovery t echniques. Now, you m ight be t hinking, what do wat erm arks have t o do wit h int rusion det ect ion? As we cont inue our st udy of risk and it s applicat ion in t he field of int rusion det ect ion, keep in m ind t hat t he dangerous enem y is not t he one aim lessly running t hree- year- old canned at t acks! The dangerous

enem y is t he one who knows what he want s and uses a hard- t o- det ect t echnique t o get it . USA Today ran a st ory in t he wake of 9/ 11/ 2001 t hat Bin Laden used st eganography t o send m essages relat ed t o t he at t ack. There are m ore pragm at ic exam ples. I n t he case of a graphics com pany, it s im ages are it s crown j ewels. To t he com pany, t his is t he night m are scenario: an at t acker who can rem ove t he proof t hat it is t he owner of t he im ages and possibly even brand t he im ages under anot her com pany's nam e. M it iga t in g or Re du cin g t h e Risk What if we decide t hat even t hough it is risky t o st rap ourselves t o a rocket , t he end result of doing so is wort hwhile? Perhaps our obj ect ive is great er t han j ust a free drink of Tang; perhaps we have an opport unit y t o be t he first hum an t o set foot on Mars. The ent erprise is st ill very risky, but we are cert ain t hat t his is som et hing we want t o do. I n t his case, if we aren't foolhardy, what we do is t ry t o find ways t o m ake t he endeavor less risky; we reduce t he risk. Have you ever t hought about int rusion at t acks against lapt op com put ers? Most professionals carry t hem t hese days. They oft en have sensit ive inform at ion about t heir organizat ion on t hem . We have already m ent ioned inform at ion- gat hering m alicious code, but t hat can be direct ed against any syst em . How specifically are lapt ops vulnerable t o at t ack? What can you do t o m it igat e t heir vulnerabilit y? N e t w or k At t a ck

I f t he organizat ion uses I nt ernet service providers ( I SPs) t o connect for em ail rat her t han secured dial- in, t here is an opport unit y t o at t ack t he organizat ion's syst em s while t hey are on t he net . They are out side t he firewall and so t he norm al screening prot ect ions against Net BI OS and ot her Windows at t acks t hat deskt op syst em s enj oy inside t he firewall are not available t o t hem . Sn a t ch a n d Run

I really hat e put t ing m y lapt op on t he X- ray m achine conveyor belt at airport securit y checks. I f I don't m ake it t hrough t he m et al det ect or, t his is a golden opport unit y for som eone t o st eal it because I am physically separat ed from m y briefcase in a dynam ic, crowded environm ent . Worse, I only have one shoe on because t hanks t o t he t errorist t hat t ried t o blow up t he airplane wit h his shoes, m ine are being inspect ed. Furt her, if som eone does walk off wit h m y lapt op if I rush aft er t hem , I run t he risk of get t ing shot by t he Nat ional Guard wit h t he M16s. There are also t he sit uat ions when I get t o m y dest inat ion: Do I leave it in m y hot el room when I go t o dinner, or lug it ? I don't know whet her you are worried about t he inform at ion t hat professionals in your organizat ion put on lapt ops. Aft er all, it is j ust st uff such as your design and business plans, sales and m arket ing inform at ion, perhaps a bid work- up or t wo. I

writ e t his t ongue and cheek, but if you int erview t he folks who lug t hese lapt ops around, you m ight find t hat t hey do not oft en perceive t he inform at ion on t hem as sensit ive and needing prot ect ion. I do know m y sit uat ion. I n writ ing, t eaching, and reviewing I oft en find m yself working wit h propriet ary inform at ion. I have signed several Non Disclosure Agreem ent s and have always t ried t o be careful wit h t hat inform at ion. I f a large securit y and net work com pany decides I have not prot ect ed it s inform at ion properly, I have t o face it s arm y of lawyers ( alone) . So I am inspired t o do t he best j ob I can t o prot ect m y lapt op; I look for t ools t o m it igat e t he risk. Because I know t hat connect ing t o t he I nt ernet is risky, what are som e of t he t ools t hat help prot ect m y syst em ? I have looked at several t ools. ZoneAlarm is free for personal use and works well. A lot of m y friends swear by BlackI ce, and t he t races it creat es have nice fidelit y; but , it has st eadily dropped in qualit y since t he com pany was acquired. I have found t he Nort on I nt ernet Securit y t ool act ually runs on XP, which is a plus. PGP appears t o have a personal firewall, but m y boss inst alled it on his XP and lost his abilit y t o connect t o t he I nt ernet . I went t hrough t hat wit h Windows ME when I inst alled PGP. I n bot h cases t he culprit was t he PGPNet product . Wit h t he ME com put er, I t hought about it for a while, I knew I needed PGP, but was pret t y sure I didn't need ME so I j ust wiped out t hat syst em and rebuilt it as a Windows 2000 syst em . PGP also com es wit h PGPdisk t hat prot ect s sensit ive files should t he lapt op ever be st olen or suffer an int rusion, or you can use t he Microsoft Encrypt ing File Syst em on Windows 2000 and XP. Alt hough PGP has a disk overwrit e, dat a- dest ruct ion rout ine, I find BC Wipe from ht t p: / / www.j et ico.sci.fi/ t o be a bet t er t ool for m y purposes. There, t hat is m y personal exam ple of im plem ent ing count erm easures t o m it igat e risk. Tr a n sfe r r in g t h e Risk Last week, when I wasn't dealing wit h out bound ft ps, I was dealing wit h flood dam age. The t oilet upst airs got st opped up ( wit h a lit t le help from m y t eenager) . The chain t hat drops t he st opper j ust happened t o chink and not drop t he st opper flush t o seal t he wat er. So, t he wat er filled t he t oilet bowl and poured over ont o t he bat hroom floor and began it s j ourney in search of sea level. But wait , t here's m ore! This happened t o be t he day t he cit y decided t o flush t he fire hydrant s, which st irs up all kinds of rust , so it wasn't clear wat er pouring t hrough t he house; it was blood red. When m y wife got hom e, t he wat er was pouring from t he dining room chandelier like a fount ain. The plast er ceiling had huge cracks and t he wooden floor had already warped in t wo places. The wat er cont inued on, accum ulat ing unt il t he ceiling of m y wife's sewing room collapsed, spewing rust y wat er and soggy ceiling t ile on her m achine and t he proj ect s below. My wife called m e at work, asking where she should begin. " Turn off t he wat er, m ove away from t he dining room , I 'm on m y way," I answered. I use t he sam e incident - handling t echnique for everyt hing. As I hung up t he

phone, it hit m e t hat t his had t o be 20 t o 30 t housand dollars wort h of dam age. I was very sad as I drove hom e and t hen busy as we t ried t o salvage what we could of m y wife's sewing room . I t wasn't unt il lat er at night t hat it hit m e. I have insurance! I n fact , I have insurance wit h a good com pany, one t hat has always t reat ed m e well. I always knew owning a hom e had risks t hat were beyond what I could financially accept . There j ust aren't good enough hom e firewalls t o expect t hem t o defend against t oilet s t hat get j am m ed and st uck on a day t hat t he cit y is purging t he fire hydrant s. Like m ost hom eowners, we had chosen t o t ransfer t he risk. So I called Travelers. They cam e over, were very sym pat het ic, and said t hey were going t o t ake care of us. Sure enough, I was only out $100 for t he deduct ible; and t he j ob would have been done except t hat no one t old m y wife t he five lit t le words you never say t o a cont ract or. St ill, even aft er a " while you are at it ," it only cost m e an ext ra $2,500 and now I have crown m oldings on t he ceiling, som et hing I am sure I always want ed. So how does t his not ion of t ransferring risk apply t o inform at ion assurance and int rusion det ect ion? I n t he first place, t here is a direct correspondence. Several agencies, including Lloyds and I BM, are now offering hacker insurance. They usually require t he organizat ion t o do it s part before insuring t hem , and t heir part is likely t o include firewalls, vulnerabilit y assessm ent s, and int rusion det ect ion, at least it would if I were offering such insurance. We have discussed uncert aint y and how it applies t o risk. We have proposed t hat som e risks we are willing t o accept ( whet her or not we are aut horized t o do so) , and ot her risks we are not willing t o accept . I n t he last case, we need t o eit her m it igat e t he risk or t ransfer it . Now, we need t o deal wit h t he issue of what agent is going t o pot ent ially do us harm ; we call t his t he t hreat . Vulnerabilit ies are t he gat eways by which t hreat s m anifest t hem selves.

D e fin in g t h e Th r e a t " Um m , I wouldn't go t here if I were you" . " Why not ?" " Bad t hings will happen t o you if you go t here." " What bad t hings?" " Bad t hings." This is not a com pelling scenario, t rue? Most of us would not be persuaded by it . I m agine giving a sim ilar pit ch t o m anagem ent : I f you don't fund an int rusiondet ect ion syst em , bad t hings will happen t o us. We need t o define and quant ify bad t hings:

z

What t hings?

z

How bad?

z

How likely t hey are t o occur or repeat ?

z

How do you know?

z

What support do you have for your answer?

So for each t hreat we can define and enum erat e, we need t o answer t hese quest ions. H ow Ba d—I m pa ct of Th r e a t I n t he end, risk is evaluat ed in t erm s of m oney. This is t rue even if life is lost ; in t he case of loss of life, it m ight be a lot of m oney. For any t hreat we have defined, we t ake t he value of t he asset s at risk and m ult iply t hat by how exposed t hey are. This yields t he expect ed loss if we were t o get clobbered by t he t hreat . This is called t he single loss expect ancy ( SLE) and t he form ula t o calculat e SLE is as follows:

Asset value x exposure factor = SLE

The exposure fact or is an est im at e, ranging from 0 percent t o 100 percent of our loss of t he asset . Consider t he following calculat ion, t he t hreat of a nuclear bom b exploding j ust above a sm all t own whose t ot al asset s are wort h 90 m illion dollars:

Example Nuclear bomb/small town ($90M x 100% = $90M)

Now let 's bring it hom e. I have already m ent ioned t hat when I have conduct ed vulnerabilit y scans of sit es wit h UNI X com put ers I have found a num ber of syst em s wit h t he t oolt alk vulnerabilit y. Can we apply t his form ula t o t hese? First , we have t o define t he t hreat . Suppose we are a Class C sit e. The t hreat is a m alicious at t acker who gains root , exploit s any t rust m odels, encrypt s t he file syst em s, and holds t he com put ers ransom for $250,000. The at t acker scans t he net and finds six vulnerable syst em s. The buffer- overflow at t ack quickly yields root . Aft er exploit ing t he t rust m odels of t hese syst em s, our at t acker is able t o root com prom ise four addit ional syst em s and t herefore encrypt t he disks of 10 UNI X workst at ions. So when t he CEO of your organizat ion com es in t o work on Monday, his secret ary finds t he following in his em ail box:

To: John Smith, CEO From: Dark Haqr Subject: Rans0m I 0wN U L^m3r It wi11 c0st u a kwart3r Mi11i0n t0 g3t ur dAtA b^k.

What is our SLE at t his point ? We could say $250,000, but it m ight not be quit e t hat sim ple. I f t here were backups, we m ight be able t o rest ore from backups and j ust lose a day or t wo of work. I f t here aren't backups ( please, please ensure t here are always backups) , we have a m ore int erest ing problem . At t his point , we don't act ually know if we will ever get t he encrypt ion key. The t hreat is t hat we will not . So, t he value of t he asset s is t he value of t he dat a on t hese syst em s, plus t he t im e t o rebuild t hem from scrat ch, plus t he loss from t he downt im e. How do we calculat e t he value of t he dat a? The value of dat a can be approxim at ed by t he burdened labor rat e of t he people who have been working on t he syst em for t he life of t he proj ect ( s) on t he syst em . To keep t he num bers sim ple, we will consider each of t he UNI X syst em s t o be a professional's deskt op. They are working on a single proj ect t hat is t wo years along and t hey each m ake $60k, but t heir burdened rat e ( benefit s, office space, and so on) is $100k. Ten people at $100k, for t wo years is $2 m illion dollars. What is our degree of exposure? I t 's 100 percent ; t he files are already encrypt ed. So, we quickly see t hat paying t he quart er m illion and keeping our big m out hs shut and not involving law enforcem ent is probably in our best int erest . So in t his scenario, we pay t he m oney, get t he key, and get back t o work and everyone is happy. Now, what happens if we don't fix t he vulnerabilit y? Fr e qu e n cy of Th r e a t —An n u a lize d Annualized loss expect ancy ( ALE) occurs when a t hreat / vulnerabilit y pairing can reasonably be expect ed t o be consum m at ed m ore t han once in a given year. I n a brief given t o t he Joint Com put er Securit y Conference in March 2000, Dr. Gene Schult z post ulat ed t his m ight be an inadequat e m easurem ent . Given t he nuclear bom b exam ple in our sm all t own, t his can't happen; indeed, we drop as m any bom bs as we want on t he t own, but we aren't likely t o cause any furt her dam age. ALEs fit very well int o m odels such as shoplift ing, ret urns in t he m ail- order business, and default s on loans. I n a com pet it ive environm ent ( e- business, for exam ple) , however, how m any ALEs event s can you survive? Consider t he case of dist ribut ed denial of service. I f your web st orefront is shut down four or five t im es in a m ont h, som e of t hat business goes t o your com pet it ion. How do you recover from t hat ? How do ALEs fact or int o inform at ion assurance and int rusion det ect ion? I m ent ioned earlier t hat int rusion- det ect ion t echnology is easily applied t o unaut horized use det ect ion. I also t hink t hat t his can be a wast e of skilled int rusion- det ect ion analyst s. But , t here is a powerful business argum ent t hat says t his is a very wise use of t he syst em and personnel. As we work t hrough t he following exam ple, not e t hat even t hough I kept t he num bers ridiculously low, we st ill ended up wit h som e serious m oney, enough t o pay t he burdened rat e of t hose

ent ry- level professionals t he organizat ion says it can't afford. Use t he following form ula t o calculat e ALE:

SLE x Annualized rate occurrence = Annual loss expectancy

This is not hing m ore t han our SLE t im es t he num ber of t im es it could be expect ed t o occur in a year. This is why we ended t he encrypt ed file syst em exam ple wit h t he quest ion, " What happens if we don't fix t he t oolt alk vulnerabilit y?" Dark Haqr t akes our m oney, goes out and buys a Beam er, his friends inquire of t he m eans of his sudden fort une, and we get t o play t he gam e again. Let 's do a com m on exam ple: Web surfing on t he j ob rat her t han working. First , we need t o calculat e an SLE. Say we have 1,000 em ployees, 25 percent of which wast e an hour per week surfing:

$50/hr x 250 = $12,500

To calculat e t he ALE we observe, t hey do it every week except when on vacat ion:

$12,500 x 50 = $625,000

You can see why an organizat ion m ight want t o leverage it s invest m ent in int rusion- det ect ion equipm ent and personnel t o curb unaut horized use. Again, I kept t he num bers m uch lower t han what I have observed t o be t he case at m any sit es. Also, in t he real world, t he wast e doesn't t end t o be spread evenly across em ployees, but rat her is localized in a sm all num ber of em ployees. I f t hese em ployees can be ident ified and canned ( aft er all, if t hey weren't working, t hey probably aren't really needed) , t here are a num ber of pot ent ial savings for t he organizat ion. Re cogn it ion of Un ce r t a in t y How reliable are t he answers from t hese SLE and ALE calculat ions? I f we are going t o m ake decisions based on t hese calculat ions, we need t o know how reliable t hey are. I spent a long aft ernoon wit h a gent lem an who was t rying t o convince m e t o invest a lot of m oney in an int rusion- det ect ion fram ework. This t hing would do everyt hing but wax your car: it had sensor fusion, aut om at ed correlat ion of vulnerabilit ies wit h incom ing at t acks, and even fact ored in virus report s in a very cool graphics display. " Best of all," he says, " it has an expert syst em ." He cont inued t alking and I nodded from t im e t o t im e, but I was already gone. I couldn't help but rem em ber phrases from m y art ificial int elligence ( AI ) classes.

How about t his one, " The reason expert syst em s don't live up t o t heir prom ise is t hat t he rules we are put t ing in t hem aren't very good. The knowledgeable engineer int erviews t he expert s in t he field, but what we are learning is t hat t he expert s aren't very expert ." Here is anot her, " One of t he biggest problem s wit h AI is when t he syst em doesn't know what it doesn't know. I n t hat respect , AI syst em s are exact ly like people." When we calculat e SLEs and ALEs, we need t o be sensit ive t o what we don't know, t o t he places we fudge t he num bers, t o t he cases where t he m odels j ust don't fit . " No problem ," you m ight be t hinking. " I have no int ent ion of calculat ing SLEs." Um m , m aybe you do som et hing sim ilar, but you do it in your head wit hout a process or docum ent at ion. I work in an organizat ion t hat m onit ors net works, for inst ance, alt hough I guess t hat doesn't com e as a surprise. I was list ening t o a new em ployee briefing and t hey were t old very clearly t hat pornography was forbidden and t hat if caught , t he responsible em ployees would probably be escort ed out t he door and fired. Let 's j um p int o t he m ind of one of t hese young new em ployees. Maybe he is curious t o see whet her t he organizat ion can det ect him if he m isspells a sexually orient ed word on a search engine, or uses oblique references. The answer is probably yes. But t hen again, he m ight t hink, " Hm m m m , but I already know t hey don't have a sense of hum or, t he SLE is j ust t oo high." Well, m aybe he wouldn't use t hose exact words, but you get m y drift . Might I share one m ore exam ple of uncert aint y in answers wit h you? I n m idFebruary 1999, I at t ended a working group for President ial Decision Direct ive 63 ( PDD 63) . The goal was t o get t he 50 or so t op researchers ( and m e) t o consider four problem areas necessary for allocat ing approxim at ely half a billion dollars in research m oney for int rusion det ect ion and inform at ion assurance. One of t he t racks was called anom alous behavior, which is Washingt on D.C. speak for t he t rust ed insider problem . So, we all worked away and t hen present ed our result s. The anom alous group present ed a finding t hat research had been funded 100 t im es m ore for det ect ing out siders t han insiders. Som eone asked, " What st udy did you find t hat rat io in, and what was your source?" The answer from our dist inguished scient ist s was " We m ade it up, but it 's close."

Risk M a n a ge m e n t I s D olla r D r ive n I f you approach m anagem ent and say you need $10,000 for an int rusion- det ect ion syst em , t hey m ight want a bit m ore inform at ion. I t is a good sign if t hey ask how m uch t im e it will t ake t o run such a syst em ; it shows t hey are list ening and t hinking clearly. A good m anager knows t he hardware and soft ware cost s are t he t ip of t he iceberg and want s t o get a handle on t he whole pict ure. Managers want t o underst and how it fit s int o t he business m odel. Risk m anagem ent ( and t hat includes int rusion det ect ion) is dollar driven.

Whenever we are faced wit h a risk t hat is unsavory t o us, we begin t o wonder what can be done t o reduce or m it igat e t he risk. As we pick our count erm easures, we should t ry t o calculat e what t hey would cost on a yearly basis. When you m ake a proposal t o m anagem ent , people really like it if you can give t he cost breakdown and even an opt ion or t wo. Rem em ber t hose SLEs and ALEs; t his is when t hey really com e in handy. The count erm easure will cost som e m oney, but look at t he risk m et rics! Here is a very im port ant aspect of pit ching risk m anagem ent t o t he organizat ion's m anagem ent : Don't nickel and dim e. The bigger pict ure you can paint of all t he risks, vulnerabilit ies, count erm easures, and get - well plans, t he m ore recept ive t hey are likely t o be.

H ow Risk y I s a Risk ? I really like t o hear host - based int rusion- det ect ion sales folks give present at ions. I t has always been an uphill bat t le, and in t hese days of personal firewalls where anyone t hat want s host prot ect ion can get it for $40 t o $60, it is becom ing com ical! The sales people get going on t he insider t hreat and play t hat issue like a harp wit h one st ring. They have t o do t his; t hey are fight ing a percept ion problem , or perhaps it would be bet t er t o st at e t his as an educat ion problem . What t hey are t rying t o do is get t he pot ent ial cust om er t o rat e one risk higher t han anot her. I f you t hink about it , t his is a com m on sales t act ic. I n Virginia, t hey don't get m uch snow, but at t he beginning of wint er, t he aut o ads are really pushing four- wheel drive vehicles. Never m ind t he fact t hat t hey cost m ore, are m ore m echanically com plex, and get fewer m iles per gallon t han t wo wheel drives; if you buy one, you don't have t o be afraid of t he snow. We can learn t wo t hings from t his: t o consider as m any risks as possible and t o keep t hings in perspect ive. We want t o be able t o rank risk. There are t wo basic approaches t o ranking risk: t he quant it at ive and qualit at ive approach. Qu a n t it a t ive Risk Asse ssm e n t The goal of t his appr oach is t o figure out what t he risk is num erically. The m ost com m on way t o do t his is asset valuat ion using our friends t he SLEs and ALEs. This is not wort h doing for each deskt op syst em in your organizat ion! I t can be a very effect ive t ool at t he organizat ion level, however, and t he num bers are not t hat hard t o dig up. To calculat e asset value ( AV) , use t his form ula:

AV = Hardware + Commercial software + Locally developed software + Data

Your com pt roller should be able t o produce your organizat ion's hardware and soft ware budget and act uals in a m at t er of m inut es. The value of locally developed soft ware is usually a bit t rickier. You have t o t ake t he burdened cost of everyone

paid t o develop soft ware for your organizat ion for som e num ber of years. Dat a is where it get s int erest ing! I sn't it t rue t hat alm ost everyone in your organizat ion uses a com put er? I f so, t he value of t he dat a is what your organizat ion has paid t o keep t hose people in front of com put ers for what ever is a reasonable life cycle for t he dat a. ( I usually use t hree years.) This is going t o be a big num ber! I t shouldn't t ake longer t han an hour t o ham m er out a reasonable value for your organizat ion's inform at ion asset s. This can be a really good t hing t o have available if you need t o persuade m anagem ent t o fund som et hing, or t o quit doing som et hing really risky. Qu a lit a t ive Risk Asse ssm e n t s You can also apply a checklist approach t o ranking risk. Generally, you have a list of t hreat s, and you rank each it em as a high, m edium , or low risk. This works m uch bet t er at t he syst em level t han t he organizat ion level. There are exam ples of a m odified quant it at ive m et hod and several checklist st yle qualit at ive m et hod risk assessm ent s at ht t p: / / www.nswc.navy.m il/ I SSEC/ Form / AccredForm s/ index.ht m l. The accredit at ion " part I I " form s at t he web sit e are for t he various archit ect ures ( Windows 95, NT, Macint osh, UNI X) are t he qualit at ive m et hod exam ples. The SCORE checklist s at www.sans.org/ SCORE are anot her resource. Finally, t he Cent er for I nt ernet Securit y ht t p: / / www.cisecurit y.org/ has a num ber of t ools t hat you can run t o assess your securit y post ure. These t ools pret end t o be quant it at ive because t hey give you a num eric score; but if you look under t he hood, you will quickly realize t hey are qualit at ive. W h y The y D on 't W or k I n t heory, bot h approaches t o risk assessm ent work fine. I n pract ice, t hey do not work so well. This is because we have a nat ural t endency not t o t ell t he t rut h, because if we do show t here is a vulnerabilit y wit h a high risk, we have t o do som et hing t o fix it . Therefore in pract ice, people who are perform ing a qualit at ive assessm ent com e up wit h num bers t hat are really big. They know t hey cannot afford t hat m uch risk, so t hey do t he assessm ent on sm aller and sm aller chunks unt il t hey get it down t o t he single deskt op syst em , and t hat is silly! Guess which box ( high, m edium , or low risk) folks doing a quant it at ive assessm ent t end t o pick. And if everyt hing is a low risk, why bot her?

Su m m a r y From t he t im e of t he Cuban Missile Crisis t o t he fall of t he Berlin Wall, if you were in t he Depart m ent of Defense and you want ed m oney, t he st rat egy was t o go t o Congress and say, " The Russians are com ing." Despit e t he way TV and t he m ovies port ray t he legislat ive branch, t hose folks aren't dum b and a lot of t hem have been on t he hill for a long t im e. So at som e point , t hey st art point ing out t hat t hey funded t his and t hey funded t hat all because t he Russians were com ing. Why hasn't t hat fixed t he problem ?

Now, we are doing it all over again t o st op t errorism , or for t he purposes of t his book, t o st op cyber- t errorism . I f you don't need your year's wort h of food and wat er and your t housand rounds of am m o for each gun t o survive hackers, you cert ainly are going t o need t hese t hings t o survive t he com ing cyber- war. Sigh. This will work t o ext ract m oney and at t ent ion for a season, but it is poor pract ice. This chapt er has covered a sound organizat ional securit y m odel. We have looked at t ools t o assess and priorit ize risk. We have a foundat ion for discussing what we do and why we do it wit h m anagem ent . The next chapt er discusses responses t o at t acks and syst em com prom ise. When we have t hese t ools solidly in hand, we can discuss how t he hackers are com ing and how t o survive a cyber- war in a reasonable m anner.

Ch a pt e r 1 8 . Au t om a t e d a n d M a n u a l Re spon se

When we were learning how t o analyze net work t races, we discussed st im ulus and response in det ail. Now, we use t he sam e concept but apply it at t he organizat ional level as we consider t he defensive responses available t o us. The st im ulus will generally be a " successful" at t ack or at t ack at t em pt . A successful at t ack, if det ect ed, invokes an incident - handling procedure. How do we define a successful at t ack? I n t he vein of " any landing you can walk away from is a good one," we can say " any at t ack t hat causes us t o t ake act ion above our norm al filt ering is a successful at t ack." Do you agree? I f not , keep in m ind t hat if we respond in any non- aut om at ed, non- norm al way, it has t o cost us resources. What I would like t o do is offer t hree at t ack exam ples. Take a look at each of t hese and consider whet her t hey are successful at t acks: z

z

z

Ping sweep. A series of I CMP echo request s from a part y conduct ing reconnaissance. Ping sweeps are usually launched from out side our int ranet or aut onom ous syst em s t o int ernal subnet broadcast addresses. They m ight be det ect ed by a sensor such as a firewall or int rusion det ect ion syst em . Disk- based survey. An em ployee receives a let t er wit h a disk. I f he places t he disk in his com put er, answers all t he quest ions, and m ails t he disk back, he receives a free T- shirt . TCP port 53 connect ions. An I nt ernet com pany t hat produces banner ads for web pages is observed pinging syst em s t hat have gone t o t hese web pages and at t em pt ed t o init iat e connect ions t o TCP port 53 on t hese syst em s.

What do you t hink? I would say t hat if your perim et er rout er or firewall blocks I CMP echo request s, t he ping sweep is not a success. I have heard folks assert t hat t his is j ust a reconnaissance probe, not an at t ack; but t he quest ion is, does it cost you resources? I was looking at a net work t race recent ly in which t he at t acker was going aft er only act ual live syst em s. I t is kind of scary when t hey know what

t hey are looking for. The disk- based survey? Cert ainly, t his is a successful at t ack. Most em ployees would never know which files were scanned or added t o t heir syst em , but it is cert ainly t rue t he at t acker get s t he benefit from t he inform at ion t he em ployee t ypes int o t he survey—and your organizat ion is foot ing t he bill. As a securit y professional, you should inform your organizat ion's em ployees t o t hrow t hese disk- based surveys st raight int o t he t rash, or if t hey m ust , t ake t hem hom e t o fill t hem out . The sim ple DNS lookups? DNS queries happen all t he t im e, and it is hard t o det erm ine which queries m ight be reconnaissance as opposed t o t he funct ion call get host byaddr t hat occurs whenever som eone is web surfing. However, t he HTTP prot ocol headers cont ain a lot of inform at ion about t he client t hat is web surfing. Som e of t he fields include t he following: z

Host operat ing syst em .

z

Version of t he browser being used.

z

The last web server visit ed. This is t he referrer field.

Web servers rout inely collect t his t ype of inform at ion for m arket ing purposes. The collect ed dat a helps t he webm ast ers t une t he look and feel of t he pages as well as phrases t hat web client s are looking for. However, t his inform at ion can also be used t o collect inform at ion about t he web client s. I f you add DNS, and possibly net st at t ype inform at ion, you begin t o com pile an incredible am ount of inform at ion about a given I P address, or I P address range. You m ight not ice t hat I did not use any " gulpers" for t he exam ples ( wit h t he possible except ion of t he ping sweep; however, t hese are not script kiddie exam ples eit her) . I am very im pressed wit h t he philosophy of Escrim a, a m art ial art . The idea is t o t ake what ever t arget s your adversary offers and cut t hem apart ( lit erally, knives are t he prim ary weapon) a piece at a t im e. This is a fundam ent al principal of inform at ion warfare. Folks are const ant ly em ploying a wide variet y of t echniques against your organizat ion, t aking what ever is vulnerable. This is why a sound prot ect ion schem e, including defense in dept h and aut om at ed response, is so im port ant .

Au t om a t e d Re spon se This sect ion exam ines archit ect ural issues of aut om at ed response, m echanism s available t o us, and t he m ost popular im plem ent at ion—Port Sent ry —as well as t he aut om at ed response capabilit y of personal firewalls. Obviously, t he cheapest and easiest response is t he aut om at ed response. This form of incident handling should be widely pract iced and, if done wisely and wit h care, is safe. There are a couple of

got chas we will address from t he st art . Because int rusion- det ect ion syst em s have a problem wit h producing false posit ives, you m ight err and respond against a sit e t hat never at t acked you. The good news is t hat you could t ake a num ber of passive defenses. These passive responses I describe do not cause harm . You would have t o have rocks in your head t o hit a suspect ed at t acker back wit h an aut om at ed exploit due t o t he pot ent ial for error from I P spoofing and false posit ives. The ot her problem is t hat if your at t acker det erm ines t hat you have aut om at ed response on, he m ight be able t o use t his against you. I m agine set t ing up t he equivalent of an Echo- Chargen feedback loop involving t wo sit es' aut o- responding int rusion- det ect ion syst em s and a couple of spoofed addresses. Or, at a m aj or deadline, t he at t acker could t arget a sit e wit h spoofed at t acks from it s part ner/ cust om er/ supplier addresses and cause t he firewalls t o isolat e from one anot her so t hat t he deadline cannot be m et . Ar ch it e ct u r a l I ssu e s Because net work- based int rusion- det ect ion syst em s are generally passive, j ust t apping t he bit st ream , t hey do not usually respond t o an at t acker's st im ulus. However, m any com m ercial im plem ent at ions of int rusion det ect ion have t he capabilit y t o connect direct ly t o t he firewall and t his com binat ion allows for aut om at ed response. I n fact , hogwash, a firewall im plem ent at ion based on Snort , act ually int egrat es t he t wo funct ions, and t here are sim ilar com m ercial product s under developm ent . The DMZ or I nt ernet connect ion is an obvious place t o im plem ent aut om at ed response, but t here are ot her very effect ive opt ions t hat include int ernal firewalls and t he host syst em s t hem selves. Re spon se a t t h e I n t e r n e t Con n e ct ion

The closer t o your sit e's I nt ernet connect ion t hat you apply aut om at ed response, t he m ore effect ive it will be; but t he risk of harm t o t he organizat ion com ing from spoofing and m anipulat ion also rises quickly. A prim ary reason for t his is t hat your I nt ernet connect ion is generally unfilt ered—t hat is, aft er all, where you put your firewall and filt ering rout er. This m eans t hese devices can be hit wit h any possible address ( spoofed or not ) , 65,535 TCP port s wit h any num ber of flag and opt ions com binat ions, 65,535 UDP port s again wit h opt ions, I CMP, fragm ent at ion, and all of t he I P prot ocol t ypes. This is a lot of space t o defend against . Now a " deny all t hat is not specifically allowed" policy will prevent t he overwhelm ing bulk of t hese possibilit ies from penet rat ing your perim et er, but t he risk com es when we t ry t o int erpret all t his using an aut om at ed policy. The bot t om line, t hough, is t hat in t he face of a rapidly increasing t hreat , and wit h t he need t o respond in t he t im e it t akes t o evaluat e a single packet , aut om at ed response is probably going t o be widely im plem ent ed. And because you get t he biggest bang for your buck by put t ing t he capabilit y near t he I nt ernet connect ion, we will probably cont inue t o see solut ions like hogwash and Tippingpoint 's Unit yOne ( www.t ippingpoint .com ) .

I n t e r n a l Fir e w a lls

Aut om at ed response using int ernal firewalls is m uch safer because t he t raffic an int ernal firewall receives generally is at least part ially filt ered. Also, you know your policy bet t er. I f you are defending five m achines or so wit h your int ernal firewall, you have a pret t y good idea wit h whom t hose host s should be t alking and on what port s. Of course, t he cat ch is t he aut om at ed response covers a lot less area. And t here are cost issues bot h for hardware and soft ware and also adm inist rat ion. The good news is a num ber of appliance and near- appliance devices need alm ost no configurat ion. The DSL and cable m odem revolut ion has creat ed a huge m arket for t hese, and t here are a num ber of opt ions including appliance product s from Cisco, Linksys, Net gear, and Sym ant ec. I really like t he lit t le $500 PI X, but t ry put t ing your hands on one; t hey seem t o be perm anent ly sold out . Because Net work Address Translat ions ( NATs) are so effect ive at prevent ing at t acks and t he lower end devices run about $250, t here is no reason not t o deploy t hem t hroughout your organizat ion. I f people do widely deploy boxes like t hat , I m ight have t o find a new line of work. I n fact , I am already working on m y delivery: " Would you like a hot apple pie wit h t hat order?" H ost - Ba se d D e fe n se s

Aut om at ed response on t he host is clearly where you get t he m inim um bang for t he buck, but t his is widely pract iced, and t he risk from spoofing is m uch lower t han a perim et er solut ion. The indust ry t rend is t wofold: int ernal appliance t ype firewalls and host - based firewall defenses. A num ber of people, especially in universit y environm ent s, depend ent irely on soft ware such as Psionic's Port Sent ry for t heir UNI X syst em s. Port Sent ry blocks an offending host from m aking any furt her connect ions and even drops t he rout e so t hat t he host cannot get back t o t ry again. The PC world has a large num ber of personal firewall solut ions. Because t his is an aut om at ed response chapt er, we should m ent ion t he am azing BackOfficer Friendly, www.nfr.com / product s/ bof/ index.ht m l. This is far m ore t han a personal firewall! Perhaps we could consider it a honeypot or even an act ive defense solut ion. I f you have a Windows syst em and want t o get st art ed learning about aut om at ed response, download t his and give it a look. The only downside is t hat it hasn't really been updat ed as t he t hreat s increase. I m agine what would have happened if t hey had m anaged t o incorporat e LaBrea t echnology early in t he Code Red days! The good news is t hese host - based defense syst em s are very effect ive, becom ing m ore prevalent , and are fairly easy t o inst all, configure, and m aint ain. Why do people depend so heavily on t hese program s? Oft en, t hey are securit y- conscious adm inist rat ors at sit es wit h no filt ering from t he I nt ernet what soever! There are four m ain sources for unfilt ered addresses: z

Cable m odem s and DSL

z

Com m ercial organizat ions t hat don't care

z

Universit ies in t he nam e of academ ic freedom

z

Connect ing while on t ravel such as at an Et hernet equipped hot el

The cable m odem and DSL world is going t o be an ever- increasing t hreat t o sit e defenders, so m aybe I don't have t o worry about pushing hot apple pies on t he fast - food drive- t hrough aft er all. I have inst rum ent ed a num ber of cable m odem connect ions and t end t o receive bet ween about 5 and 20 probes per day. Hundreds of people are hooking up t o cable and DSL everyday, and m ost of t hem have unprot ect ed syst em s. This is som et hing we becam e very aware of in 2001 wit h Code Red, nim da, and Leaves. Most cable m odem st yle defenses such as NATs and host - based firewalls do not im plem ent aut om at ed response; but it isn't a bad t rade: int rusion prot ect ion for int rusion det ect ion. Com m ercial organizat ions t hat are inept or don't care and connect t o t he I nt ernet will not survive t he t ransit ion t o an inform at ion econom y.Yet , a surprising num ber of sit es eit her do not have a firewall or have inadequat e perim et er prot ect ion. When you connect your organizat ion t o t he I nt ernet , you will be probed and t est ed. I f your syst em s are not com bat ready and can be seen from t he I nt ernet , t hey will fall. I f you are lucky, you get t he playful sort s of at t ackers, but even t hen your syst em will likely be used t o at t ack and probe ot hers. A com m ercial organizat ion wit h a com prom ised syst em could share a far worse fat e if t he at t ackers decide t o use it t o acquire corporat e secret s. As we suggest ed earlier, if I were in business, in addit ion t o a m ain firewall, I would st rongly consider t he use of int ernal appliance t ype firewalls. Aft er you get inside t he perim et er of m any facilit ies, t hey have neit her det ect ion nor prot ect ion capabilit y. Key host s would do well t o have syst em level prot ect ions. The int erest ing bat t leground t hat I have been wat ching for several years is t he universit y world. Many of t hese sit es have no firewalls or filt ering at all. Already, I have seen depart m ent s set up t heir own firewalls in universit ies t hat don't want t o put one at t he front door. And, syst em prot ect ions are popular wit h proact ive adm inist rat ors. A fully open I nt ernet connect ion is an archaic and brain- dead t hrowback t o academ ic freedom , and I doubt t he pract ice will survive anot her four years. I t will be fun t o wat ch. The academ ics t hat claim all packet s m ust be free t o t ravel t he I nt ernet will probably back down soon enough. Just wait unt il t heir depart m ent 's budget suffers a 50 percent cut due t o t he universit y losing a m aj or lawsuit brought by a dot .com t hat lost significant revenue when t he universit y's syst em s were com prom ised and used in an at t ack. Connect ing while on t ravel requires a bit of t hinking. I oft en carry a sm all Linksys rout er hub wit h m e, so t hat I have t wo layers of defense: t he NAT and m y personal firewall. Also, it allows m y wife and I t o be online at t he sam e t im e; when you are used t o being online for 14 hours a day, you aren't very good at t aking t urns t o check your m ail. The NAT allows m e t o m it igat e t he risk t o m y relat ionship and m y im port ant docum ent s—what could be sweet er? I underst and t hat you m ight have reservat ions about im plem ent ing aut om at ed response. I t ry t o set t hings up in class and show a num ber of int rusion det ect s

from Decem ber 24 and 25 and com m ent t hat Christ m as is a special t im e of t he year. Then, when we com e t o t he aut om at ed response discussion, I point out t hat during t he Christ m as and East er vacat ions people are norm ally not around, but syst em s are st ill up. This can be an excellent t im e t o experim ent wit h aut om at ed response at t he I nt ernet connect ion. Because very lit t le work is get t ing done, especially at Christ m as, t his is a fairly low- risk t im e t o t ake your aut om at ed response syst em s out for a spin and see what t hey are capable of. Next , let 's work t hrough our response opt ions. I t is a good idea t o keep in m ind t he previous discussion about where t he analysis and response funct ions are best accom plished. Th r ot t lin g This is a sm art response t o port scans, host scans, SYN floods, and m apping t echniques. The idea is t o begin t o add delay as a scan or SYN flood is det ect ed; and if t he act ivit y cont inues, cont inue increasing t he delay. This can frust rat e several script - driven scans such as ping m apping t o 0 and 255 broadcast addresses because t hey have t o rely on t im ing for t he UNI X/ non- UNI X t arget discrim inat ion. Ent erasys and Cisco bot h have rat e lim it ing. I n fact , any device you can int erface wit h t hat support s Qualit y of Service should be usable in t his fashion. Throt t ling can also be done at t he prot ocol level. For UDP, t he I DS could forge a source quench. For TCP, if t he t raffic goes t hrough a proxy firewall, t he out bound int erface could send a sm all window size. I would avoid using t he LaBrea t rick of a window size of 1. At t ackers will be looking for t hat next t im e around, but 5, for inst ance, will drast ically slow down t he at t ack. D r op Con n e ct ion

Dropping t he connect ion is st raight out of t he st ring- m at cher handbook. When I say " connect ion," of course I am t alking TCP prim arily, but t he sam e general effect for UDP can occur using a shun ( as discussed in t he next sect ion) . The at t acker est ablishes a connect ion t o an act ive port . Then he sends t he packet , or packet s ( for int rusion- det ect ion syst em s such as Cisco Secure I DS or Snort wit h packet re- assem bly capabilit y) , t hat cont ains t he at t ack st ring, or exploit . This is t he point of great danger for a vulnerable syst em . The I DS det ect s t he st ring and orders t he firewall t o drop t he connect ion. Now, you m ight have a com prom ised syst em , but t he at t acker can't m ake use of t he com prom ise direct ly. I n t he case of a buffer overflow, t he vict im com put er is now running what ever code was beyond t he com m and lengt h and is probably running it as root . I f it is a grappling hook t ype program ( a sm all t elnet daem on running on som e predefined port ) , dropping t he connect ion m ight only buy you a few seconds. Sh u n

I am going t o cont inue t he at t ack j ust described wit h t he shun t echnique, and t hen discuss why shun m ight be one of t he m ost im port ant aut om at ed and m anual t echniques at your disposal. As t he at t ack progresses, you have a new process running as root t hat has opened up a t elnet daem on or sent back an X Window or what ever open door int o our vict im syst em t he at t acker has chosen. Dropping t he connect ion does not help, because he is already planning t o init iat e anot her connect ion; or in t he case of an X Window, you have init iat ed t he connect ion t o him from our side. Shunning m ight buy som e relief. When you shun, you do not accept any m ore t raffic t o or from t he offending I P address. This is a good t echnique and can be execut ed on j ust t he offending host or on it s subnet work. A capabilit y t o look for whet her you want t o im plem ent shun is a " never shun" file ( also called a whit e list ) ; you can place t he addresses of your cust om ers and suppliers in t his file. This prot ect s you from an at t acker being able t o spoof t hese addresses wit h som e obvious script kiddie at t ack j ust t o isolat e you from t he syst em s you do business wit h. Shunning does not help you if t he at t acker is using t wo address fam ilies, which is fairly com m on. My friend Pedro Vasquez sent m e a t race from Brazil wit h a DNS buffer- overflow coordinat ed at t ack t hat did exact ly t his. The at t ack cam e from one host and t he X Window was displayed t o anot her host . Just because shunning does not help you in every case, however, doesn't m ean you shouldn't em ploy t he t echnique.

Pr oa ct ive Sh u n n in g I t t urns out t hat a num ber of I nt ernet service providers and even whole count ries cannot , or will not , m anage t heir host s. Over t im e, as you have been doing int rusion det ect ion, you com e t o realize t hat an incredible num ber of t he at t acks t hat you and your friends deal wit h ( you are sharing dat a, right ?) com e from t he sam e net work addresses. Why play wit h fire? Event ually, t hey will find a way t o burn you! Block t hem . Let m e t ake t his a st ep furt her: be willing t o block t hem at t he t wo oct et or 16- bit m ask. Be willing t o block a whole count ry. Nobody is get t ing arrest ed for hacking, and it doesn't look like t hat is going t o change any t im e soon. I f count ries t hat will not cont rol t heir " research net works" st art t o be m arginalized and are unable t o reach large part s of t he I nt ernet , however, t hey will have t o com e t o t he t able and t alk t urkey. We have been experim ent ing wit h t his on t he SANS web server, and one single I SP t hat has open proxies has been t he source net work of m ore at t acks t han any ot her address group. We shunned t hem for about t wo m ont hs; t hey wrot e and m ade prom ises, so we let t hem back int o t he sit e and wit hin a day, we were at t acked again. We are considering a perm anent ban at t his point .

I sla n din g I slanding is t he aut o- response of last resort . The idea is, if a sufficient num ber of at t acks occur over a t im e period ( usually during t im e periods during which no analyst is on dut y) , t he int rusion- det ect ion syst em sends a com m and t o an X10 or sim ilar logic- cont rolled relay and drops t he power t o t he rout er. The result of t his is isolat ion of t he sit e from t he I nt ernet . Alt hough t here is serious pot ent ial for a denial- of- service condit ion, t his can be a reasonable st rat egy for t hree- day weekends at high- securit y sit es. This capabilit y can be hacked t oget her wit h a few lines of code wit h any int rusion- det ect ion syst em t hat issues SNMP t raps. On second t hought , m aybe t hat SNMP t rap idea is not so sm art . Aut om at ed response does have a risk of self- inflict ed denial of service. Only do som et hing like t his if you are willing t o have t he deadfall occur on any given " red- alert " alarm condit ion. SYN / ACK Suppose t he int rusion- det ect ion syst em knew t he port s t hat a sit e blocked wit h it s firewall or filt ering rout er. Furt her, suppose t hat every t im e t he I DS det ect ed a TCP SYN packet t o one of t hese blocked port s, it answ ered back wit h a forged SYN/ ACK. The at t ackers would t hink t hey were finding lot s of pot ent ial t arget s; however, all t hey would be get t ing is false posit ives. I f you t hink about it , t he lat est generat ion of scanning t ools has caused a lot of problem s for t he int rusiondet ect ion com m unit y wit h t heir decoy capabilit ies. This would be a great way t o answer back. I finally got t o see t his in act ion. Som e friends of m ine got a Rapt or firewall. This works great . The at t acker com plet es t he t hree- way handshake and t hinks he has a vict im . He even sends dat a wit h t he lone ACK, so you can see what he is up t o. Re se t This is t he so- called Reset kill or as t he Snort folks say, session sniping. I have serious reservat ions about t his t echnique. The Reset kill can t ear down som eone else's TCP connect ion, and I have seen com m ercial I DS syst em s fire t hese kills based on false posit ives. The idea is if you see a TCP connect ion t hat has been est ablished and t he I DS det ect s a signat ure t hat requires act ion, you forge t wo Reset s and send one t o bot h sides t o blow off t he connect ion. I t used t o be possible sim ply t o sm ack t he init iat ing host , but at t ackers are learning t o ignore Reset s. This isn't used all t hat oft en, alt hough it is available in Snort and com m ercial int rusion- det ect ion syst em s.

H on e ypot An advanced sit e, in conj unct ion wit h t hrot t ling, can use it s rout er t o direct t he at t acker t o a specially inst rum ent ed syst em called a honeypot . The honeypot could be used as a st and- in for t he t arget ed host . We also have used honeypot s wit h st at ic addresses as st and- ins for int ernal host s t hat have becom e "hot ."

Every once in a while, a host t hat you are prot ect ing will suddenly st ir up a lot of int erest and you will keep seeing probes and exploit at t em pt s direct ed t o it . I n such a sit uat ion, a fun course of act ion is t o change bot h it s nam e and I P address and inst all a honeypot in it s place. However, t he m ost com m on use we have at ht t p: / / www.incident s.org/ for honeypot s is t o figure out what t he at t ackers are doing by cat ching t heir at t ack in a honeypot . I have t ried t hree t ypes of honeypot s: a proxy syst em , t he Decept ion Tool Kit ( DTK) , and an " em pt y" com put er, t he Honeynet approach. Pr ox y Syst e m During 1996 and 1997, I did a lot of research int o hacker t echnology. The goal of t he proj ect was t o collect as m any exploit t ools as possible. I t ook a Sun com put er running SunOS 4.1.3, pat ched it as best I could, and inst alled t he TI S t oolkit . The syst em was nam ed cray3. I copied an / et c/ m ot d from a Unicos syst em and did everyt hing I could t o m ake it look like a cray. Thank goodness t his was before TCP fingerprint ing. I used t he TI S t oolkit for t he t arget services, ft p, t elnet , SMTP, and so fort h. Finally, I com piled I nt ernet Relay Chat ( I RC) . The idea was t o spend t im e on t he hacker I RC channels, exchange code, get people t o at t ack m y syst em , and collect t he t echniques t hey used. There was only one sm all problem . I had never been on I RC! I knew t hat if I didn't do it right t hat I would show up like I had five legs and a t ail. So what t o do? I decided t o st art in a channel ot her t han # hack. So I t ried # t hirt ysom et hing. I have never been good at flirt ing, so I ended up wast ing hours wat ching words fly by on t he screen. Next , I decided t o t ry # Jesus. I figured church people would be nice t o m e. BZZZZT, t hey kicked m e off wit hin 10 m inut es. I was really crushed! Finally, in frust rat ion, I signed on t o t he # abort ion channel because t hat was what was about t o happen t o m y proj ect . They were som e great folks, alt hough st rongly polarized on bot h sides of t he issue. Best of all, t hey were willing t o let a newbie learn t o chat . Aft er a week or so pract icing m y social graces, I ent ered # hack, but t here was j ust one last lit t le hit ch. We had agreed t hat any hint of ent rapm ent was out side proj ect param et ers and because I was doing t his for t he DoD, I found m yself on # hack wit h a .m il source address. Well, t hat brought back m em ories of elem ent ary school and " Kick Me" signs t aped t o m y back; kick m e t hey did. However, I won a TCP t rivia challenge or t wo, and aft er a while, we m anaged t o get t hings going. I t was a lot of fun, and t hey couldn't resist at t acking t he .m il syst em , so we were able t o collect a lot of fun dat a. D TK The Decept ion Tool Kit was aut hored by Fred Cohen and is available at ht t p: / / all.net / dt k.

I t is writ t en in a com binat ion of Perl and C and em ulat es a large num ber of services. DTK is a st at e m achine, can em ulat e virt ually any service, and com es ready t o do so out of t he box for a num ber of t hem . I t used t o be pret t y easy t o com pile and set up. As it has been im proved t o be m ore realist ic, however, it has st art ed t o becom e a bear t o build. This st at e m achine approach is essent ially what BackOfficer Friendly is, and as I writ e t his Marcus Ranum is writ ing anot her honeypot for SANS st udent s t o t ry. Em pt y Syst e m Not hing looks m ore like UNI X t han UNI X, or Windows NT t han Windows NT. So in som e sense, t he perfect honeypot is j ust a syst em t hat is a lit t le older and slower and has a sm aller disk ( t he sm aller t he bet t er, in case you loose t he bubble) . Then, you inst rum ent t he heck out of t he syst em and collect inform at ion as folks t ry t o exploit it . This has been t aken t o near science by t he Honeynet t eam . I ncident s.org is a m em ber of t he Honeynet alliance and has a vm ware- , ht t p: / / www.vm ware.org/ , based Honeynet wit h a firewall, int rusion det ect ion syst em , and a couple of running operat ing syst em s all running on a single m achine.Vm ware is t he closest t hing t o m agic I have ever seen. Lat ely, t here have been som e t roubling indicat ions t hat som e of t he honeypot s and Honeynet s on t he I nt ernet have been ident ified and t heir I P addresses are being passed around in t he underground so t hat t hey avoid t hese syst em s. H on e ypot Su m m a r y Honeypot s are an advanced t echnique. They can be low yield for t he effort one has t o expend. On t he ot her hand, if you block wit h your firewall or filt ering rout er, you never get t o collect t he at t ack if you filt er. A honeypot enables you t o collect t he at t ack. I f you don't have a hot syst em , t he best t hing t o do is set your honeypot up as eit her your DNS, web, or em ail relay syst em . These syst em s are rout inely added t o at t ackers' shopping list s. The good news is you can collect at t acks; t he bad news is you collect t he sam e at t acks over and over again.

M a n u a l Re spon se I nt rusion- det ect ion analyst s oft en serve a double role as lead for incident handling, or as a handling t eam m em ber. Please get one t hing st raight in your head right now: You are going t o t ake a hit . Bet ween t he out sider t hreat from t he I nt ernet , t he insider t hreat , and t he m alicious code t hreat , you are definit ely going t o t ake a hit . Analyst s som et im es get in a m indset t hat t hey are responsible t o prot ect t he organizat ion.You can't ! We don't expect rescue- squad workers t o ensure no accident s occur on I - 95, right ? We j ust ask t hem t o help in a professional m anner aft er t he accident has occurred. Consider what I have said carefully. I have led a large int rusion- det ect ion t eam wit h m any sit es and have seen several analyst s develop a m indset t hat t hey are personally responsible t o

m ake sure no at t acks get t hrough. I f we are going t o t ake a hit , a syst em com prom ise can't be t he end of t he world. Rat her, t he point is t o deal wit h it as effect ively and efficient ly as possible. Because t here m ight be som e st ress involved, we want a clear, well- defined process t o follow. Think about CPR; t hey have t heir pit hy acronym , ABC. The ABCs of CPR are as follows: z

Airway. Make sure it is clear.

z

Breat hing. Are t hey?

z

Cardiac. Beat ing or not beat ing?

I found t he following six- st ep process in a governm ent publicat ion in 1995. I have been working t o refine t his m odel ever since. The six st eps are as follows: z

Preparat ion

z

I dent ificat ion

z

Cont ainm ent

z

Eradicat ion

z

Recovery

z

Lessons learned

This chapt er doesn't discuss preparat ion or ident ificat ion; aft er all, m ost of t his book is devot ed t o preparat ion and ident ificat ion. Cont a in m e n t I n incident handling, you learn t o m aint ain a reasonable pace; if you hurry, you m ake m ist akes and t hat can be cost ly. There is one place t o really m ove out , however, and t hat is cont ainm ent . I t is bet t er t o deal wit h t wo affect ed com put ers t han four and bet t er t o deal wit h one com prom ised workgroup t han a whole Windows dom ain. Good incident - handling t eam s can work in parallel. This is really im port ant in cases in which m ult iple syst em s m ight be involved. As soon as t he dat a has com e in, I j ust m ake a copy, circle t he addresses I need a t eam m em ber t o handle, and hand him t he paper. Usually, I don't have t o say m ore t han m y t radem ark " t ake good not es people, good not es." The first t hing t o do in cont ainm ent is t o st art reducing net work connect ivit y. Fr e e z e t h e Sce ne

My first course of act ion is t o pick up t he phone and call t he person nearest t he syst em console. The language in t he following sect ion has been developed over years of hard- knocks experience. You are a t echnical person; t he person you are calling on t he t elephone m ight not be. Also, as he realizes t here is a problem , he m ight be under som e st ress. Of course, you will develop your own script s and t echniques, but I call t he individual wit h a suspect ed problem and say: Please t ake your hands off t he keyboard and st ep away from t he com put er. Thank you. Now, in t he back of t he com put er t here is a net work connect ion, please find it and rem ove it from t he com put er. My nam e is St ephen Nort hcut t , what is your nam e? Pleased t o m eet you ______, and where is your office? Sure, we know where t hat is. ________, can I get your phone num ber and any ot her office phones t hat you know? You have done a fant ast ic j ob. We'll be right t here; now do you have a fax m achine? Great ; while t he t eam is on it s way, I am going t o fax you a set of inst ruct ions. _______, we need your help and I would appreciat e it if you would st art as soon as your receive t he incident handling guide. Can you t ell m e what operat ing syst em t he com put er is? These are crit ically im port ant lines. The t rick is t o say as few words as possible t o get t he point across. However t he " noise" or non- cont ent words such as please, t hank you, and fant ast ic, are very im port ant ; we need t o de- st ress t he sit uat ion if possible. Despit e t he at t ackers, I keep learning t he hard way t hat our biggest danger is what we do t o our evidence and ourselves. I am also working on m y voice inflect ion. I don't have a really com m anding, powerful voice, so I t ry t o speak wit h aut horit y, slower t han m y norm al pace, and t ry t o proj ect kindness and em pat hy. Sa m ple Fa x For m

Securit y Office @UR Organizat ion On Sit e Com put er I ncident Response Form Revision 2.1.1 Dat e: Tim e: Print ed Full Nam e: Thank you for not ifying t he securit y depart m ent of t his incident and agreeing t o help. Please do not t ouch t he affect ed com put er( s) unless

inst ruct ed t o do so by a m em ber of t he I ncident - Handling Team . I n addit ion, please rem ain wit hin sight of t he com put er unt il a m em ber of t he t eam get s t here and ensures t hat no one t ouches t he syst em . Please help us by det ailing as m uch inform at ion about t he incident as possible. We need a list of anyone who direct ly wit nessed t his incident ; please list t heir nam es below. I f you need m ore space, please cont inue on a separat e sheet of paper: Wit nesses: 1) 2) 3) What were t he indicat ions t hat you observed t hat led you t o not ice t he incident . Please be as specific and det ailed as possible. I ncident indicat ors: This next sect ion is very im port ant . Please be as accurat e as possible. From t he t im e you not iced t he incident t o t he t im e you called t he I ncident - Handling Team , or help desk, please t ry t o list every com m and you t yped and any file t hat you accessed. Com m ands t yped and files accessed: Signat ure: ______________________________________ On - Sit e Con t a in m e n t

Whenever possible, we suggest t wo people be dispat ched t o t he scene. One handles t he sit e survey, and t he second t eam m em ber, t he m ore experienced, should work at cont aining t he com put er syst em . Sit e Su r ve y

The survey m em ber should use a port able t ape recorder and describe t he scene. Record t he nam es of everyone in t he vicinit y, if possible. Order everyone in t he vicinit y who was not t here when t he incident occurred, does not norm ally work in t he area, or isn't t he syst em owner, t o leave. While t he on- sit e handler is set t ing up t he backup, int erview t he individual who phoned in t he incident . Det erm ine t he indicat ions of t he incident . Work wit h t he em ployees in t he area t o check t he ot her com put er syst em s t o see whet her t here are indicat ions of com prom ise on t hese syst em s. Be cert ain t o cont inue t o record what you are seeing, or if you can't use a recorder, m ake sure t o t ake good not es. Every few m inut es, shoulder surf t he incident handler and m ake a t im e- st am ped not at ion of what you observe her

doing; t wo records are bet t er t han one. Syst e m Con t a in m e n t

The handler should t ry t o get t he norm al syst em adm inist rat or for t his syst em t o ride shot gun. Ask him t o help you t ake good not es. One of your prim ary goals is t o m ake a backup of t he syst em if at all possible. Experienced handlers oft en have t heir own privileged binary applicat ions and t his includes backup program s. I f you do not possess your own forensic- t ype backup and seizure t ools, such as safeback, it m ight be wiser t o copy all hist ory files and log files t o rem ovable m edia before t aking any ot her act ion. I ncident handlers are supposed t o writ e t he cont ent s of m em ory t o rem ovable m edia as well; while easily said, however, t his has proven t o be hard t o do in pract ice. The best backups are bit - by- bit backups. I f t his opt ion is not possible, t he next quest ion t o answer is how crit ical t he syst em is and how t im e pressing t he incident is. I f crim inal act ivit y is suspect ed and t here is reason t o believe t hat t his act ually is an incident , it m ight be best t o do as follows: z

Power down t he syst em

z

Pop t he drive

z

z

Seal it in an envelope wit h a copy of your not es and t he not es from t he person who called in t he incident St ore t he drive in an evidence safe or locked cont ainer wit h lim it ed access

H ot Se a r ch

I f it is a crit ical syst em and crim inal prosecut ion is not a priorit y, you m ight have t o search t he syst em hot t o find t he problem . This is where a t ool such as Encase or The Coroner's Toolkit ( TCT) can really com e in handy. Bot h t ools are available for bot h old Windows ( FAT) and m ore m odern Windows ( NTFS) file syst em s. Before running eit her t ool, I like t o run Tripwire on bot h t he search drive and m y host operat ing syst em before I st art . That way, if som et hing goes horribly wrong, I have an idea where t o look for t he problem . There used t o be a forensics t ool called Expert Wit ness, but it died in a lawsuit . I was doing a hot search of a drive t hat was infect ed wit h a virus and t he next t hing I knew I was infect ed wit h a virus. Now of course, t he forensics t ool sales represent at ive is going t o t ell you t his could never happen wit h his t ool and he is probably right , but why t ake t he chance? I n any case, your goal is t o det erm ine whet her t he evidence on t he syst em reasonably support s t he report ed indicat ions. This is known as validat ing t he incident , and it is not lim it ed t o t he inform at ion on t he suspect hard drive. A good t eam doesn't leave a handler all alone; hopefully, som eone is working t he

int rusion- det ect ion syst em 's records and ot her sources of dat a looking for inform at ion about t he affect ed syst em while you are focused on t he suspect syst em 's hard drive. Er a dica t ion Som et im es, it is possible t o exam ine t he sit uat ion and rem ove t he problem ent irely; ot her t im es, it is not . Wit h eradicat ion, we need t o pause for an upwardly m obile career observat ion about incident handling. I f folks in an organizat ion have suffered one com prom ised com put er or six, t hey are usually pret t y scared. I f your t eam com es in and you are court eous and professional and get t he j ob done, t hey really appreciat e it . When t hey see you in halls and st aff m eet ings, t hey nod and kind of say t hanks wit h t heir eyes—it is a good t hing.You are sort of a hero. I used t o have t his really cool j ob in t he U.S. Navy where I flew around in helicopt ers wait ing for j et s t o go sm acking int o t he wat er. Then we would hover over t he ej ect ed pilot s and I would j um p out and swim up t o t hem , hook t he crew up t o a cable hoist , and we would pull t hem out of t he ocean. You want t o know what t hey always said when I swam up t o t hem ? Whenever I ran int o t hem on t he ship aft er t he rescue, t here was t hat sam e nod and saying t hanks wit h t heir eyes. However: I f you show up and do your work and t he problem com es back t he next day, you are not a hero; you are an incom pet ent idiot . I t is crit ical t hat you succeed in eradicat ion, even if you have t o dest roy t he operat ing syst em t o do it . Repeat aft er m e, " Nukem from high orbit ." See, t hat isn't hard t o say. Or, " Tot al eradicat ion is t oo good for 'em ." I have t ried t o inj ect a lit t le hum or, because we m ust deal wit h a serious issue. As an incident handler, you need t o be pre- aut horized t o cont ain and dest roy t o save your organizat ion. Please t ake t he preceding sent ence very seriously. The incident - handling t eam needs t o have a very senior execut ive in t he organizat ion as it s sponsor or cham pion. The handler m ust be able t o look t hat very young, very successful program m anager droid, who has axed m any a prom ising t echnical person on a whim , in t he eye and say, "Yes, I know how im port ant t his syst em is. We will save as m uch of t he dat a as your people have properly backed up, but t he operat ing syst em is t oast ." Many t im es, t he only way you can be cert ain t he problem has been elim inat ed is t o scrub t hat puppy t o bare m et al. Oh yeah, when I swam up t o t hese navy pilot s, t hey always want ed t o know " what happened?" They asked t heir quest ions in such a way t hat it was clear t hey want ed t o know exact ly one t hing: Was it t heir fault ? Might I suggest t hat when you handle an incident , t he folks you com e in cont act will be very concerned t hat t he incident was t heir fault . Why our cult ure is so bent on blam ing t he vict im is beyond m e! Be gent le and com fort ing when you speak. Don't com e t o conclusions early. Many t im es, running an incident t o ground is like peeling an onion a layer at a t im e. Even if you know in your very bones it is t heir fault , be kind and support ive during t he incident . The t im e t o deal wit h what happened com es soon enough!

Re cove r y The purpose of t he incident - handling process is t o recover and reconst it ut e capabilit y. Throughout t he process, we t ry t o save as m uch dat a as we can, even if t he syst em hadn't been backed up in a long t im e. Oft en, we can m ount a pot ent ially corrupt ed disk as a dat a disk and rem ove t he files we need from it . This is anot her good applicat ion for Tripwire. Before m ount ing a suspect disk on your field lapt op, m ake sure you have a very current Tripwire running so t hat you can be cert ain m alicious code doesn't get on your com put er. Em ergency m edical t echnician ( EMT) t rainers use scenarios t o drive hom e t he academ ic point s t aught . One of t he im port ant lessons t o t each EMTs is not t o becom e a vict im , because t his m akes t he rescue even m ore problem at ic. I f you see som eone prost rat e on t he ground draped over a cable, for inst ance, don't run up t o him and t ouch him . What if t he cable is t he reason t hey are lying t here dead? What will happen t o you when you grab som eone connect ed t o a highvolt age cable? The point is t o use sit uat ional awareness and t ake a few seconds t o t hink about t he circum st ances t hat caused t he com put er t o be com prom ised. I n t he exact sam e way t hat failing t o eradicat e t he problem m akes t he incident handler look st upid, we do not want t o put t he syst em back in business wit h t he sam e vulnerabilit y t hat caused it t o be com prom ised. This is an im port ant point , because we will probably alt er t he syst em in som e way. I n fact , m any t im es, t he syst em owners will want t o use t his as an unexpect ed opport unit y t o upgrade t he syst em , or freshen t he pat ches. I find it am using when t he sam e m anager who looked m e in t he eye during t he cont ainm ent phase and said t hings like, " Do you know how crit ical t his syst em is? You can't shut it down," suggest s t hat we upgrade t he operat ing syst em before ret urning t o service. I t is all well and good t o freshen t he operat ing syst em . However, what happens when an out sider m akes a change t o one of our syst em s? I oversaw t he inst allat ion of a firewall once at a facilit y t hat didn't have one. For t he next five years, every t im e som eone couldn't connect t o som et hing, or t heir soft ware didn't work right , I would get phone calls and/ or em ail. " I s it t he firewall?" This is a career risk vect or t o t he incident handler. Rem em ber our very young, very successful, hell- bent - on- rising- t o- t he- t op execut ive? I f anyt hing goes wrong, he m ight use t hat t o deflect at t ent ion from t he fact t hat a syst em in his group was com prom ised. What count erm easures can we t ake? During t he incident - handling process, I like t o keep t he syst em owners inform ed. As long as t hey are in danger, t hey are very int erest ed. As soon as t hey can see t hey are going t o m ake it , t hey usually t urn t heir at t ent ion t o som et hing else. I t is im perat ive t hat early in t he cycle, while t he adrenaline is st ill flowing, t o pull t hem aside and say som et hing like t his: Sir, our prim ary obj ect ive is t o get you back in business wit h as lit t le downt im e and as few problem s as possible. I am sure you underst and t hat because t he

syst em was com prom ised, we will have t o m ake at least som e m inor changes t o t he archit ect ure, or it is likely t o happen again. To ensure t hat t he changes we m ake do not im pact your operat ions, we need a copy of t he syst em 's docum ent at ion, especially design docum ent s, program m aint enance m anuals, and m ost im port ant ly, your syst em t est plan. We will be glad t o work wit h your folks t o execut e your syst em t est plan before we close t he incident . Now, you and I bot h know t hat m aybe five com put ers on t he planet eart h have an up- t o- dat e, com prehensive t est plan. There is no way on God's green eart h t hat our slick young m anager is going t o be able t o produce it . Tim e t o invoke t he power of t he pen. We produce our preprint ed incident closure form . I t has blocks on it for t he syst em adm inist rat or, prim ary cust om er, and syst em owner t o st at e t hat t hey have t est ed t he recovered syst em and t hat it is fully operat ional. So you say som et hing like t his: No t est plan? Um m m , well sir I can't close an incident out unless t he syst em has been cert ified as fully operat ional. Tell you what , if you will get your people t o run t he t est s t hey use t o cert ify your syst em s and docum ent t hose t est s and sign t he form , t onight , we can get t his incident closed. I am willing t o st ay as long as it t akes because as you know, t he CI O's goal for incident handling is for downt im e t o never exceed one day, and we can't clear t his syst em for operat ion unt il it has been t est ed. I invest ed a couple of paragraphs m aking t his public safet y announcem ent . I t is really a bum m er when a prom ising young incident handler get s blam ed for syst em problem s aft er pouring her heart out t o save a com prom ised syst em . Now t hat you know t he risk, pract ice safe incident - handling procedures. Aft er a syst em has been com prom ised, it m ight becom e a hacker t rophy. The at t acker m ight post his exploit in som e way. I have seen several inst ances in which aft er a syst em is com prom ised, recovered, and ret urned t o service, t he at t ackers com e out of t he woodwork t o whack it again. Use your int rusiondet ect ion capabilit y t o m onit or t he syst em closely. I t m ight be possible t o m ove t he syst em t o a new nam e and address and inst all a honeypot for a few weeks. Le sson s Le a r n e d At first , t he incident was excit ing and everybody on t he planet want ed t o get involved. There was t he hunt for t he culprit , sift ing t hrough clues t o find t he problem , and reconst ruct ing t he chain of event s t hat led t o t he incident . Then com es t he slow process of recovery and t est ing. This is less fun and folks are leaving, saying t hings like, " I guess you guys can t ake it from here." Finally, we are done. The problem is cont ained, eradicat ed, and t he syst em is recovered. We are all drained and possibly a bit punchy. The last t hing in t he world you want t o hear is, " t he j ob ain't finished unt il t he paperwork is done." Two disciplines dist inguish t he professional from t he wannabe: The pro t akes

com plet e and accurat e not es every st ep of t he way and does a good follow up. Bot h of t hese are disciplines; t hey do not com e nat urally. Every t im e you handle an incident , m ist akes will occur. Mist akes also had t o occur or t he incident could have never happened. But t hat is a t ouchy subj ect , so t read light ly. Things could always have been done bet t er. I t is okay t o m ake m ist akes, j ust m ake new ones. " Lessons learned" is t he m ost im port ant part of t he process when approached wit h t he correct m indset . I t should never be a blam e t hing, rat her an opport unit y for process im provem ent . Here is t he approach t hat has worked for m e. The incident handlers are responsible for docum ent ing t he draft of t he incident report . As soon as t hey finish it , t ypos and all, t hey send a copy t o each person list ed as a wit ness, prim ary cust om er, and syst em owner. Anyone can m ake any com m ent he want s, and his com m ent s will be part of t he perm anent record. The handlers m ake t he call whet her t o m odify t he report . Wit hin a week of t he incident , a m andat ory m eet ing should be held. Book t he room for exact ly one hour and st art on t im e. The only order of business at t he m eet ing is t o review t he final incident report 's recom m endat ions for process changes. One- hour m eet ings are not good places for t he consensus approach. Just t ally t he vot es for each it em . The final report goes t o t he senior execut ive who is t he sponsor of t he t eam . The m ost im port ant sect ion of an incident report is t he execut ive sum m ary. This is where you docum ent why having a crack incident - handling t eam saved your organizat ion a lot of m oney.

Su m m a r y We face risks wit h every user or program we add t o our syst em s and wit h every service we open on our firewall. Effect ive response, bot h aut om at ed and m anual, is an effect ive m it igat ion t echnique. I t enables your organizat ion t o m ove a bit fast er and a bit m ore aggressively in t his fast - paced world. Som e of t he aut om at ed responses include t hrot t ling t o slow down t he at t ack, dropping connect ions, shunning t he at t acker if he at t em pt s t o reconnect , islanding from t he I nt ernet in serious at t acks, prot ocol t ricks such as sending SYN/ ACKs even if t he host or service does not exist , and Reset kills. Every organizat ion has an incident - handling t eam ; som e j ust haven't form alized one. A form al t eam following t he six- st ep process of preparat ion, ident ificat ion, cont ainm ent , eradicat ion, recovery, and lessons learned will probably be m ore effect ive t han an ad hoc response. The int rusion- det ect ion analyst s should always be m em bers of t he t eam and oft en are excellent choices for leading it . One securit y m odel, t im e- based securit y, st at es t hat t he t im e t hat we are prot ect ed is prim arily based on t he t im e it t akes us t o det ect and react t o an at t ack. As we t une our aut om at ed and m anual responses, we t rain t o react fast er and hopefully bet t er, increasing t he prot ect ion we provide for our respect ive

organizat ions.

Ch a pt e r 1 9 . Bu sin e ss Ca se for I n t r u sion D e t e ct ion

" Where do I st art ? What is t he best I D t ool t o use?" A st udent asked t his quest ion aft er he had j ust com plet ed t he m ost advanced class we t each on t he subj ect of int rusion det ect ion, our hands- on, im m ersion curriculum . I was m ore t han a lit t le surprised by t hat quest ion. We had spent t he past six days and evenings hands on, learning about covert channels, m alform ed packet s, and TCP fingerprint ing wit hin a connect ion. We had worked and worked t o show t he st udent s why t here is no silver bullet , why every I DS needs t o be backed up by a net work recorder t hat capt ures all t he t raffic. I decided t o answer wit h a quest ion. To t he quest ioner, I m ust have sounded like som eone from Oz, but what I said was, " I f your organizat ion doesn't current ly have an int rusion- det ection capabilit y, why should t hey acquire one now? What 's changed?" I f your organizat ion doesn't current ly have an int rusion- det ect ion capabilit y, it will oft en be an uphill effort t o cham pion one. To paraphrase Newt on, an organizat ion at rest t ends t o rem ain at rest . We are com ing t o t he close of t his book and before we m ove t o our final chapt er, t he fut ure of int rusion det ect ion, I would like t o consider t he business case for int rusion det ect ion. This is an im port ant subj ect . The chapt ers t hat precede t his one give t he sense t hat t he knowledge required t o be an analyst is very t echnical, but fun. Also, I am sure you have a sense t hat t he j ob of t he int rusion- det ect ion analyst wit h new det ect s and live at t acks is excit ing and challenging. Everyone t hat I know in t he field is having a great t im e, but t hat isn't a good reason t o deploy int rusion det ect ion in your organizat ion. I f you m ade it past t he first half of t he book, you probably have a t echnical bent ; so do I . But t hat isn't enough. Three of m y heroes in int rusion det ect ion, Ron Gula, Marcus Ranum , and Mart y Roesch, have all st art ed t o say, " As a businessm an…." Each of us is in business in som e sense. This is st ill t rue if we work for t he governm ent , a universit y, or a not - for profit . I f you are even t hinking about int rusion det ect ion, your organizat ion probably is fairly well funded. We have t aken pains t o develop a t echnical and

archit ect ural fram ework, but also t o consider t he business issues of risk m anagem ent . I f your I D capabilit y does not fit in your organizat ion's business m odel, it will be a source of frict ion. Let 's work t oget her t o develop t he st rat egies and processes needed t o package int rusion det ect ion for an organizat ion. This chapt er was writ t en for securit y professionals who: z

z

z

Don't current ly have an int rusion- det ect ion capabilit y and are considering t he m erit s of acquiring one Have a rudim ent ary capabilit y and are considering a follow - on procurem ent or upgrade Have an exist ing capabilit y and t he organizat ion is downsizing or rest ruct uring and is in t he process of evaluat ing t his j ob funct ion

I n t hese cases, you aren't going t o succeed by " wow ing 'em " wit h t echnology. Appeals t o dut y or alarm ist cries, "The hackers are com ing, t he hackers are com ing," will not suffice t o keep t his proj ect funded for t he long haul— alt hough it m ight well shake loose m oney for an addit ional purchase. This chapt er lays out a t hree- part plan t hat shows t he im port ance of int rusion det ect ion. The first part of t he plan covers m anagem ent issues, what I call t he " fluffy st uff." Part one isn't t echnical, but it serves as t he backdrop t o allow m anagem ent t o support t he int rusion- det ect ion plan. Part t wo of t he plan answers t he quest ion " Why int rusion det ect ion?" This is where you discuss t he t hreat and t he vulnerabilit ies; t his is where you draw heavily on what you have learned about risk. Part t hree offers your solut ions and t radeoffs. The goal is t o creat e a writ t en report t hat serves as t he proj ect plan and j ust ificat ion. I have t ried t o lay t his out so t hat it m akes a nice present at ion as well, because t hat is how one norm ally briefs senior m anagem ent t hese days. Each it em in a bullet ed list is a suggest ion for a PowerPoint slide. For ext ra credit , cut and past e t he appropriat e m at erial from your writ t en report int o t he not es sect ion of t he PowerPoint slides and suggest t hey be print ed wit h not es pages showing. Few people t ake t he t im e t o do not es pages, so t his will show you have it t oget her. All present at ions and report s t o m anagem ent should st art wit h an int roduct ion called an Execut ive Sum m ary. This is where you sum up t he t hree m ost im port ant point s you are going t o m ake. When you brief senior m anagem ent , always be prepared t o have your t im e cut short . " Can you do it in five m inut es?" is not an unheard of request . I n t hat case, you will show exact ly t hree slides: your Execut ive Sum m ary, Cost Sum m ary, and Schedule. The Execut ive Sum m ary is followed by a Problem St at em ent , in which you define t he problem you are t rying t o solve. You probably want t o ext ract a nice sound bit e from t he inform at ion in

part t wo of t he report for t his. Your t hird slide is a roadm ap where you define t he st ruct ure of t he present at ion.

Pa r t On e : M a n a ge m e n t I ssu e s Your goal is t o show m anagem ent t hat t his is part of an overall int egrat ed inform at ion- assurance st rat egy t hat has t angible benefit s t o t he organizat ion. The key t o doing t his is t o show t hat your proposed solut ion has t he following charact erist ics: z

Bang for t he buck.

z

The expendit ure is finit e and predict able.

z

The t echnology will not dest abilize t he organizat ion.

z

This is part of a larger, docum ent ed st rat egy.

Ba n g for t h e Bu ck You need t o be realist ic. I nt rusion det ect ion is fairly cost ly. You need t wo fast com put ers ( $2.5k each) . I f you choose com m ercial int rusion- det ect ion solut ions, t he soft ware license ( $10k, t o st art ) , m eans t hat it cost s $15k j ust t o say int rusion det ect ion. The net work m ight need t o be alt ered and t here is t he __ work- year salary and overhead for t he int rusion- det ect ion analyst ; you could easily be t alking $100k. But wait , t here is m ore, bandwidt h is increasing, so you need six sensors and a Top Layer swit ch j ust t o wat ch t he web farm , add anot her $100K. You need a dat abase t o search for slow speed scans and a correlat ion engine wit h a hardware RAI D t o hold all t his dat a, add anot her $150K easily. I n an environm ent focused on cost reduct ion, you are going t o have t o show a significant benefit t o j ust ify t his expense. The good news is t hat you can do exact ly t hat . Risk is part of t he business equat ion. I n fact , t here are m arket s t hat buy and sell denom inat ed risk every day. Did you skip over t he risk chapt er? What is one way an int rusion- det ect ion syst em helps reduce t he annualized loss expect ancy ( ALE) ? By observing t he at t acks against your organizat ion, t he analyst can assist t he organizat ion in fine- t uning it s firewall and ot her defenses t o be resist ant t o t hese at t acks. I s t hat wort h $100k $350k? I f not , here is anot her way an int rusion- det ect ion syst em helps reduce loss. To conduct business, you m ight find t hat cert ain applicat ions, or sit uat ions, require t hat som e vulnerabilit ies need t o be left on syst em s. A com m on exam ple is t hat when you apply t he recom m ended securit y pat ches t o a syst em , it breaks som e applicat ion. The int rusion det ect ion can be focused on t hat part icular vulnerabilit y. I n fact , t his is an ideal opport unit y t o use t hat Reset kill you have been it ching t o t ry. There is a bang for t he buck using int rusion- det ect ion syst em s.You can show it , and you can quant ify it .

I n t r u sion D e t e ct ion Usin g Fir e w a lls One of t he incredible changes on t he m arket has been firewalls t hat log full binary dat a. OpenBSD's I PFilt er and t he com m ercial Rapt or firewall can log dat a in BPF form at . This binary logging allows you t o run Snort or TCPdum p filt ers against t his inform at ion. This is incredible! I have already m ent ioned hogwash and Unit yOne, firewall appliances wit h an I DS capabilit y built in. My personal preference is t o use t wo devices—if one fails t he ot her cont inues t o run. Also, firewalls t hat do not have a binary logging capabilit y can st ill be used in int rusion det ect ion. As an exam ple, Dshield ( www.dshield.org) , t he t echnology t hat powers incident s.org, uses firewall dat a for it s largescale int rusion- det ect ion capabilit y. Firewalls cert ainly can be sensors. To be sure, firewalls t hat do not log m ost of t he TCP header field values, such as TCP flags, only allow for very lim it ed analysis. I f you have a firewall wit h t he fidelit y of a Linux firewall ( such as I Pt ables, for exam ple) , however, you can do a lot of t he t raffic- analysis t echniques you have learned in t his book. I f you do not have an I DS available, you can and should begin t o apply what you have learned from t his book by reviewing your organizat ion's firewall logs. Needless t o say, get perm ission first and be slow t o raise alarm s! Th e Ex pe n dit u r e I s Fin it e You know t he old adage about a boat being a hole in t he wat er you t hrow m oney int o. I was reading a Sunday paper colum n recent ly t it led, " Ten Tips on How t o I ncrease Your Personal Wealt h." One of t he t ips was don't buy a boat ; if you have a boat , sell it . I am not so int erest ed in wealt h t hat I am ready t o dit ch m y boat s, but t hey do keep cost ing m oney ( and t hey are m ost ly sea kayaks) . Here is one m ore house st ory t hat will help you underst and a senior m anager's concerns about cont aining expense. One day, I realized t hat everyt hing I did was done on a sm all fleet of lapt ops and a cell phone wit h a t rillion m ont hly m inut es. I n t hat m om ent , I realized I could live anywhere I want as long as t he area has cell t owers and DSL or bet t er. My wife and I set t led on Hawaii, and as luck would have it , DoD called t he next day and asked m e t o do t wo weeks of consult ing on an I DS visualizat ion proj ect on Oahu, so Kat hy and I flew down t o t he islands. Two weeks lat er, we bought a dream house on Kauai on t he rim of a canyon overlooking t he Wailua River halfway bet ween t he rainforest and t he beach. A m ont h aft er we m oved in, t he dream house becam e a night m are house as it suddenly set t led int o t he soft eart h of what had form erly been a pineapple field. A parade of insurance agent s cam e t hrough claim ing it was not covered, followed by st ruct ural engineers saying t hey had never seen t his before. Finally, a wise local

point ed m e t o t he best cont ract or on t he island, Luis Solt ren—t ruly t he best cont ract or I have ever seen—but t he house was t ot aled. Luis, like anyone who is t he best at what he does, is not cheap. I t was t he m oney pit , ( never wat ch t hat m ovie if you are rem odeling) , up close and personal. Every t im e t hey pulled a piece of sheet rock or a t ile, we would find m ore problem s. Luis would shout for one of us and we would look and shudder. I did rem odeling in college, have built a house, and roofed dozens, so I know a bit about t he t rade, and Luis was spot on— t hese were all m ust - do repairs. The bill kept get t ing higher and higher. When it crossed, no j oke, $200k, I was sick t o m y st om ach, and it kept going. We are finally done, and I learned a very im port ant lesson. The phrase t ot al cost of ownership is very popular in inform at ion t echnology, and I never really considered it unt il I was caught in a proj ect , m y house, where it wasn't possible t o calculat e what t he final cost s were going t o be; t hey j ust kept going up. Now, let 's apply what we have learned from t his st ory t o int rusion det ect ion and your organizat ion's senior m anagem ent . Keep in m ind t hat good m anagers t reat every dollar as if it is t heir own, and uncont rollable cost s m ake t hem feel t he way m y house m ade m e feel. When it com es t o int rusion det ect ion, m anagem ent m ight well be willing t o pay t he $100k or what ever, but m anagem ent needs t o be shown why t he expenses you propose in your plan are probably correct and t hat you aren't going t o have t o com e back for m ore and m ore m oney. For inst ance, a classic error is t o plan on using older, last - generat ion PCs for t he int rusion syst em . I propose t he opposit e. Buy t he lat est - generat ion PCs for int rusion det ect ion, and aft er six m ont hs t o a year, roll t hem out as deskt op m achines. Managem ent will appreciat e t his as an honest and workable approach. I t gives t he organizat ion t he best possible int rusion- det ect ion capabilit y and t he hardware upgrades are essent ially free because buying new deskt ops is part of t he com put ing life cycle. Te ch n ology Use d t o D e st a bilize The signat ure line of t he hym n " Am azing Grace" is " I once…was blind, but now I see." This is what an int rusion- det ect ion syst em does: I t helps an organizat ion go from a blind st at e t o a seeing st at e. Tim e and t im e again, st udent s who t ake t he int rusion- det ect ion curriculum we t each at SANS go back and st art looking at t heir dat a and t hey realize t hey really need t o change t he way t hey do business. This is a good t hing! However, it is a change, and people are suspicious of and resist ant t o change. When you propose int rusion det ect ion, you m ust be sensit ive t o t he pot ent ial for organizat ional change and m ake every effort t o show t hat t he I DS will " fit in." Som e of t he pot ent ial im pact s t o t he organizat ion are t he configurat ion of t he net work, t he effect s on behavior of em ployees, and t he need for addit ional policy support . N e t w or k I m pa ct s

We have discussed t he challenges of deploym ent on swit ched net works. This needs t o be carefully coordinat ed wit h t he net work operat ions people before t he purchase order for t he I DS is cut . The best t hing t o do is t o get t he spanning port working wit h a prot ocol analyzer; m ost net work operat ions groups have one or m ore prot ocol analyzers. I f t he spanning port is difficult for your net works operat ions people t o configure and m aint ain, net work t aps should be considered for t he list ening port s on t he I DS. Many people feel t hat good pract ice for an I DS sensor is t o be provisioned wit h m ult iple int erface cards: z

z

List ening port s in prom iscuous m ode but wit hout I P addresses. This m akes it hard for at t ackers t o find t he sensor's list ening port s. One int erface, wit h an I P address, is used t o com m unicat e wit h t he sensor.

The I DS will alm ost cert ainly require a firewall m odificat ion. Com m ercial vendors all seem t o t hink t hat writ ing t heir own propriet ary prot ocol for com m unicat ions am ong t heir I DS consoles, sensors, and dat abases set s t hem apart from t heir com pet it ion. And of course, t hey are lit erally correct . Do your hom ework and research what port s need t o be opened. I f t he I DS can be m odified t o use an exist ing hole in t he firewall, use t hat . Even proxy- based firewalls oft en have a pass- t hrough hole; a " suck- and- spit " proxy wit h no prot ocol knowledge already running t o support som e applicat ion or anot her. I t will be great when t he I nt rusion Det ect ion Working Group ( I DWG) finishes it s work and t here is a st andard t ransport prot ocol based on beep ( www.beepcore.org/ beepcore/ docs/ profileidxp.ht m l) for int rusion- det ect ion syst em s. I D S Be h a vior a l M odifica t ion

Behavioral m odificat ion is anot her aspect of running an I DS. You already know t hat I have concerns about using t he I DS as big brot her, even t hough m any organizat ions are losing a lot of m oney t o wast eful act ivit ies. The I DS is a dat a collect ion and analysis t ool, however; so even if you aren't looking for t rouble, you m ight st ill find it . You need t o be prepared as an organizat ion t o deal wit h what you find now t hat you are no longer blind t o net work t raffic. Let 's use an I RC server as an exam ple scenario. You t urn t he I DS on and soon realize t hat a bright young kid in t he com put er operat ions depart m ent has set up one of your int ernal syst em s as an I RC server. How did you find t his out if you weren't m onit oring for I RC? We have discussed t he fact t hat DNS, web, and em ail servers draw a lot of fire. That is not hing com pared t o t he fire I RC servers draw! What t he analyst s see is a ba- zillion at t acks and probes direct ed at a syst em in com put er operat ions. When you look int o it furt her, you find out t he rest of t he st ory. Obviously, t he organizat ion want s t o t urn t his around and get t he problem cleaned up. The wise analyst and organizat ion will have est ablished policy before t he I DS was powered on t o handle t hese t hings. Th e Policy

I suggest t hat t he organizat ion consider an init ial am nest y policy. By t his, I m ean t he first 10 or so violat ions of t he organizat ion's accept able- use com put er policy be dealt wit h quiet ly and in a lenient fashion. A m em o can be sent out t hat doesn't nam e anyone, but list s som e of t he exam ples and warns t hat in t he fut ure t hese act ivit ies will not be t olerat ed. I know of organizat ions t hat have t urned on t heir shiny new I DS and exam ined t heir t raffic for t he first t im e. I m agine t heir surprise when t hey see t hings t hey do not approve of ent ering and leaving t heir net work. They are now at an im port ant decision point . I f t he organizat ion react s in a kneej erk fashion and walks t he em ployee st raight t o t he door, t he I DS will always be viewed wit h suspicion and hat red. Be especially careful wit h t he way you deal wit h syst em s and net work adm inist rat ors; t hey are used t o doing what ever t hey want . I f you walk som eone from t he com put er or net work operat ions group t o t he door because t hey broke an accept able- use policy you j ust st art ed enforcing, your I DS m ight break down or suffer blindness caused by loose cables a lot in t he fut ure! Managem ent knows all about firest orm s—hat e and discont ent and t he int eract ions bet ween folks wit h st rong personalit ies. Managers deal wit h t his kind of st uff every single working day. I f your im plem ent at ion plan shows t hat you are sensit ive t o t he ot her players in t he organizat ion and t hat t he I DS is not guarant eed t o produce Excedrin headache num ber 36, t hey will be far m ore support ive of your plan. Pa r t of a La r ge r St r a t e gy This book is focused on helping t he analyst of a net work- based int rusion- det ect ion syst em . However, we have also t alked about syst em securit y, risk, vulnerabilit y scanners, unaut horized use, incident handling, and now, business issues. You need t o always be ready t o show how int rusion det ect ion fit s in as part of t he organizat ion's inform at ion- assurance program . To be honest wit h you, when I was younger, I didn't get it . I t hought m y m ission in life was t o im plem ent t he best t echnology at t he m ost affordable price possible t o help t he research lab t hat I worked for be " world class." Phrased t hat way, it even sounds like a laudable m ission. I would approach m y boss wit h a t echnology and it s t echnical t radeoffs and he would say, "Yes, but show m e t he big pict ure." I t used t o drive m e crazy. I was convinced he was a t ot al idiot wit h a personal goal of being nam ed Luddit e of t he year. Fift een years lat er, I am j ust st art ing t o really underst and. You can't play a song on a harp wit h one st ring. Any t echnology, no m at t er how wonderful, is useless unless it com plem ent s t he exist ing business processes of t he organizat ion. When you brief m anagem ent on t he spiffy I DS you want t o buy, be sure t o include t he hooks t o syst em securit y, risk, vulnerabilit y scanners, unaut horized use, incident handling, and business issues in your plan. Please allow m e t o do a quick repeat from Chapt er 17, " Organizat ional I ssues" ( see List ing 19.1) List ing 19.1 The Seven Most I m port ant Things t o Do I f Securit y Mat t ers [ 1]

[ 1]

Court esy of Mat t Bishop, Alan Paller, Hal Pom eranz, and Gene Schult z

Writ e t he securit y policy ( wit h business input ) . Analyze risks, or ident ify indust ry pract ice for due care; analyze vulnerabilit ies. Set up a securit y infrast ruct ure. Design cont rols, and writ e st andards for each t echnology. Decide what resources are available, priorit ize count erm easures, and im plem ent t op- priorit y count erm easures you can afford. Conduct periodic review s and possibly t est s. I m plem ent int rusion det ect ion and incident response. I f your int rusion- det ect ion proposal is writ t en against a process like t his, it will be obvious t o m anagem ent t hat it is part of a larger st rat egy. Senior m anagem ent does not have t he t im e t o accept inform at ion piecem eal; it is responsible for broad business st rat egies. Take a bit of your t im e t o m ake it s j ob easier. We have spent considerable t im e on t he four issues t hat m anagem ent needs t o see in an int rusion- det ect ion plan. I f we do not cover t hese bases, t heir paradigm s will not let t hem even consider t he plan. Again, t hey are as follows: z

Bang for t he buck.

z

The expendit ure is finit e and predict able.

z

The t echnology will not dest abilize t he organizat ion.

z

This is part of a larger, docum ent ed st rat egy.

Now we can m ove on t o t he t echnical st uff; t his will be part t wo of your plan or proposal.

Pa r t Tw o: Th r e a t s a n d Vu ln e r a bilit ie s The second part of t he plan is where you lay out t he t hreat s and com pare t hem t o your vulnerabilit ies and t he value of your asset s. The purpose of t his is t o answer t he quest ion, " Why do we need addit ional securit y m easures?" I t hink t hat t he highest and best purpose of net work int rusion det ect ion out side t he firewall is t o help assessm ent of t he at t acks direct ed against your organizat ion and t o ensure t he int ernal host s are hardened against t hese at t acks. But before you have an

I DS, how do you assess t hese t hreat s? You want t o exam ine t he problem , t he t hreat s, and t he vulnerabilit ies before you offer int rusion det ect ion as t he solut ion. Chapt er 17's focus on risks gave t he foundat ion you need t o approach t his sect ion of t he plan. Part t wo's elem ent s are as follows: z

Threat assessm ent and analysis

z

Asset ident ificat ion

z

Valuat ion

z

Vulnerabilit y analysis

z

Risk evaluat ion

Th r e a t Asse ssm e n t a n d An a lysis A risk assessm ent purist would say you need a dict ionary t hat enum erat es all possible t hreat s, and t hen you need t o analyze each t hreat . For a plan t o support an int rusion- det ect ion syst em t hat is designed t o be readable by m anagem ent , t his is a bad idea.Your goal is not t o show all possible t hreat s, but rat her a sam pling of probable t reat s. Managem ent and t he int rusion- det ect ion analyst would do well t o focus on what is likely t o happen t o it and how it is going t o happen. I cover t hese in reverse order. The following list is m y t ake on how t hese at t acks are going t o arrive. The prim ary t hreat vect ors are as follows: z

Out sider at t ack from net work

z

Out sider at t ack from t elephone

z

I nsider at t ack from local net work

z

I nsider at t ack from local syst em

z

At t ack from m alicious code

Th r e a t Ve ct or s

Let 's j ust t ake a second t o be sure of t he t erm t hreat vect or. I f you go t o t he rest room of a rest aurant , t here is oft en a sign saying, " Em ployees Must Wash Their Hands Before Ret urning t o Work." I t has been well est ablished t hat skipping t his sanit ary st ep is a disease vect or. The dirt y hands are t he pat hway, t he conduit t hat allows t he food poisoning. A net work- based int rusion- det ect ion syst em m ight be able t o det ect out sider at t ack from t he net work, insider at t ack from t he net work, and possibly at t ack from m alicious code ( rem em ber t he Macro virus and PKZip exam ples from Chapt er 17) .

A host - based int rusion- det ect ion syst em wit h an act ive agent m ight be able t o det ect all five vect ors. Th r e a t D e t e r m in a t ion

Your goal for t he purposes of est ablishing a business case for int rusion det ect ion is t o list well- known, probable t hreat s as opposed t o all t hreat s. How do you find t hese t hreat s? Sources m ight include t he following: z

Newspaper or web art icles on at t acks at ot her places. I f it happens t o t hem , it could happen t o you.

z

Firewall/ int rusion- det ect ion logs for specific t hreat s.

z

Syst em audit t rail logs.

z

Dem onst rat ion of an int rusion- det ect ion syst em .

Many com m ercial int rusion- det ect ion vendors allow you t o t ake t heir syst em s for a t est drive, wit h a 30- day t rial or som et hing sim ilar. I f you are serious about want ing t o im plem ent an I DS capabilit y, I can't st ress how im port ant t his is t o do. I t gives you a list of act ual at t acks against your net work; t his is helpful for est ablishing t he t hreat . I t helps est ablish t he groundwork for part t hree of t he plan when you show why you recom m end an int rusion- det ect ion syst em as opposed t o, say, anot her firewall. And, it gives you experience wit h a couple com m ercial offerings. All t oo oft en, folks m ake t heir decision eit her based on som et hing t hey read or on how friendly t he salesperson is. I f you have t ried a few " loaner" I DSs, in part t hree of t he plan, you can m ake honest st at em ent s about t he t radeoffs bet ween various syst em s. I f you can find t he t im e t o do it , int erviews wit h folks in various part s of your organizat ion can be a rich source of t hreat s and vulnerabilit ies t hat you m ight ot herwise have m issed. I have had people t ell m e about shockingly bad pract ices when I ask t hem what t hey consider t he largest dangers t o t he organizat ion's inform at ion asset s t o be. Yet , t hey never cam e forward wit h t he inform at ion on t heir own. As t hey say in Alabam a, " Whaay- el, you never asked." Asse t I de n t ifica t ion Chapt er 17 discussed asset valuat ion. Now, you focus on t he concept a bit m ore. The huge value is t he invest m ent in dat a. I f m ost of your workers use com put ers m ost of t heir workday, t he value of t he dat a on t he com put er is t he cost of put t ing t hat worker in front of t he console. The t hreat s t o t hat dat a are t hat it will be copied, dest royed, or m odified. We have t ouched on t his t hroughout t he book. So t hat we are really clear, however, I will reit erat e: The m ost probable t hreat t o t hat dat a is dest ruct ion from

t he syst em owner. As m y Cat holic friends would point out , t his could be by a sin of com m ission, or a sin of om ission. By com m ission, I m ean an overt act , delet ing t he dat a accident ally, or on purpose, and never t elling anyone so t hat it can be recovered. By om ission, I m ean t he failure t o back up t he dat a properly, and t hat includes off- sit e backup. At least for t he t hings t hat are wit hin your power t o change, work t o ensure your dat a is backed up. I t t urns out t o be an alm ost im possible t ask t o ensure t hat all t he dat a t hroughout t he organizat ion is prot ect ed from being copied, dest royed, or m odified. I n t he sam e way, m aking sure every dat a elem ent is backed up, on and off sit e, is beyond t he capabilit ies of any organizat ion t hat I know of. This is a great lead- in t o t he not ion of crown j ewels, or crit ical program inform at ion ( CPI ) as t hey say in securit y t ext s. Va lu a t ion All your dat a is not of t he sam e value. I n fact , a sm all port ion of t he inform at ion t hat exist s in your organizat ion is what dist inguishes you from your com pet it ion. Alt hough all your dat a has value, crown j ewels are t he inform at ion t hat has crit ical value and m ust be prot ect ed. You reflect t his in t he t hreat sect ion of your plan. Find as m any of t he crown j ewels as possible. Consider t he t hreat vect ors, and t he known com m on t hreat s, and use t hese as t he exam ples of t hreat s and vulnerabilit ies in part t wo of your int rusion- det ect ion business plan. I n part t hree, you will discuss count erm easures t o prot ect t hese clust ers of highvalue inform at ion. These m ight include t he following: z z

z

z

Host - based I DS soft ware on t he crit ical syst em s. Honeypot files. I f your organizat ion has sensit ive docum ent s, you can add special t agged st rings int o t he docum ent . One way t o do t his is invent acronym s t hat do not act ually exist . Then you can program your I DS wat ch for t hese wit h a st ring, or cont ent m at ching rule. This would t ell you if t hese files are ent ering or leaving your net work. I nst rum ent ing int ernal syst em s wit h personal firewalls. ( Technically orient ed em ployees oft en enj oy doing t his.) Net work- based I DS in high- value locat ions.

Vu ln e r a bilit y An a lysis Vulnerabilit ies are t he gat eways by which t hreat s are m ade m anifest . All t he t hreat s in t he world don't m at t er if t here are no vulnerabilit ies.

Were you disappoint ed because I didn't give a long list of vulnerabilit ies from which t o work? Well, t hey change alm ost daily so you need a point er t o a current list , not a st at ic one t hat will be obsolet e before t he book is even print ed. I like t he Com put er Vulnerabilit ies and Exposures ( CVE) proj ect ( cve.mitre.org) t he best because it cross- indexes a num ber of great vulnerabilit y list s such as bugt raq and I SS's X- Force. However, you do not need t o do t his m anually. Get t ing your general t hreat list as well as an assessm ent of your vulnerabilit ies is a fairly sim ple m at t er. A num ber of good vulnerabilit y assessm ent t ools are available. These t ools t est for specific t hreat s, and t hey find pot ent ial vulnerabilit ies. Let 's consider t hree classes of t ools: syst em - vulnerabilit y scanners, net work- based scanners, and also phoneline scanners. Tools such as COPS, SPI , t iger, and STAT are exam ples of syst em - vulnerabilit y scanners. They work wit hin t he syst em looking for m issing pat ches, incorrect ly set file perm issions, and sim ilar problem s. Tools such as nm ap, nessus, saint , I SS' I nt ernet Scanner, and Axent 's Net Recon are exam ples of net work- based scanners. These are fairly fast and effect ive and scan t he net work looking for unprot ect ed port s or services. While conduct ing vulnerabilit y assessm ent s, you m ight also want t o assess your risk from t he at t ackers who scan your phone lines looking for act ive m odem s. Toneloc, available from fine hacking sit es everywhere, is t he m ost used t ool for t his. Phonesweep from ht t p: / / www.sandst orm .net / is a com m ercial t ool wit h som e addit ional feat ures. I f at all possible, your vulnerabilit y assessm ent should offer t hree views: z

A syst em view. Taken from select ed syst em s wit h syst em scanners.

z

A net work view. Done from an int ernal scan of your net work.

z

An I nt ernet view. Done from out side your firewall and, if possible, a phone scan as well.

Of course, you want som e j uicy vulnerabilit ies t o spice up your report , but please also scan your firewall, DNS, m ail, and web servers, as well as syst em s relat ed t o your crown j ewels. These are t he syst em s t hat your organizat ion depends on. Whew! Sounds like a lot of work, doesn't it ? Correct , it is a lot of work and vulnerabilit y assessm ent s are not som et hing t hat should be done only once. Why does it m ake sense for t he int rusion- det ect ion analyst t o be involved in vulnerabilit y assessm ent s? I t keeps you aware of specific problem s and where in t he organizat ion your vulnerabilit ies are locat ed. Risk Eva lu a t ion

You have a lot of dat a. What do you do wit h it ? Just because you collect ed it , do not st uff it all in your report , even as labeled appendixes. On t he ot her hand, you do want it organized and available. Whenever you brief senior m anagem ent , you want at least one support ing layer of dat a available—t hat is, if your slide says 12 syst em s are deem ed t o cont ain CPI , you darn sure want t o be able t o list t hose syst em s and explain t he rat ionale for choosing t hem and not ot hers. Okay, we have answered t he quest ion of what you are not going t o put in t he second sect ion of t he report . What should you provide? z

A t op- level slide wit h t he value of t he organizat ion's inform at ion asset s. Suppose you have 100 com put ers wit h a five- year life cycle, for inst ance. The hardware, soft ware, and m aint enance cost s are $200k/ year wit h inform at ion valued at $1 m illion.

z

A net work diagram t hat defines t he boundary you are t rying t o prot ect .

z

A basic descript ion of t he t hreat vect ors.

z

A general sum m ary of your general vulnerabilit y assessm ent .

z

A descript ion of t he crown j ewels: where t hey are, t heir value, and so on ( include t he firewall, DNS, m ail, and web servers) .

z

Specific t hreat s against t he crown j ewels.

z

Specific vulnerabilit ies of t he syst em s t hat host t he crown j ewels.

This should exist as a writ t en report as well as a view- graph present at ion. I f you are doing a PowerPoint present at ion ( which is recom m ended) , expand each of t he preceding bullet s t o be a PowerPoint slide wit h t hree t o five bullet s each.

Pa r t Th r e e : Tr a de offs a n d Re com m e n de d Solu t ion Finally, you get t o pit ch your int rusion- det ect ion syst em ! You can hardly wait t o get behind t he console of t hat shiny new int rusion.com special and sm ell t hat new I DS sm ell. Slow down a lit t le longer.You need t o offer som e t radeoffs, and also rem em ber, you are going forward wit h a package. I nt rusion det ect ion by it self is a hard sell. From a risk- assessm ent , t ext book st andpoint , t he next t hing you are supposed t o do is est ablish risk- accept ance crit eria. This approach is t o put m anagem ent on t he spot and have it define what levels of risks it is willing t o accept . Then, you go back and design com prehensive count erm easures for all risks great er t han what m anagem ent is willing t o accept . Good luck! Therefore, you should do t he following: z

Define an inform at ion- assurance risk- m anagem ent archit ect ure.

z

I dent ify what is already in place.

z

I dent ify t he im m ediat e st eps you recom m end.

z

I dent ify t he opt ions for t hese count erm easures.

z

Produce a cost - benefit analysis.

z

I m plem ent a proj ect schedule.

z

I dent ify t he follow - on st eps illust rat ing where you want t o go in t he fut ure.

D e fin e a n I n for m a t ion - Assu r a n ce Risk - M a n a ge m e n t Ar ch it e ct u r e This sound like a hard chore, but it is really sim ple. You have defined t he t hreat s. You know t he prim ary count erm easures. I t could be as sim ple as im plem ent ing t he following: z

Firewall from t he I nt ernet

z

Net work- based I DS out side t he firewall

z

I nt ernal firewalls for crown j ewels

z

Net work- based I DS covering crown j ewels

z

Host - based I DS on crown j ewels' plat form s

z

Tagged honeypot files on crown j ewels' plat form s

z

Basic hardening for all syst em s, ant ivirus program s, pat ches, and good configurat ion m anagem ent t o prevent silly file perm ission set t ings

z

Organizat ional net work- based backup wit h off- sit e st orage

z

Scanning of t he int ernal net work for vulnerabilit ies quart erly

z

Cert ificat e- based encrypt ion for t ransm issions over t he I nt ernet wit h cust om ers and suppliers as well as hom e and off- sit e workers

z

St rong aut hent icat ion for dial- ins

z

Disk encrypt ion and personal firewalls for lapt ops

This list m ight not be com plet ely appropriat e for your organizat ion, but t his is m y view of t he big pict ure for inform at ion assurance.

I de n t ify W h a t I s in Pla ce Every briefing or report t o senior m anagem ent should include a st at us slide, som et hing t hat defines where you are now. I f you follow your definit ion of your inform at ion- assurance archit ect ure wit h your current st at us, it is a nice set up for t he t hings you want t o do next . I de n t ify You r Re com m e n da t ion s Finally, you get t o pit ch t he int rusion- det ect ion syst em of your dream s. You want t he pit ch t o be balanced. I t is perfect ly reasonable t o pit ch an int rusion- det ect ion syst em and a vulnerabilit y scanner ( or what ever is appropriat e for your organizat ion) at t he sam e t im e. For t he pit ch t o be solid, it should include opt ions, cost , and schedule inform at ion. I j ust cry when I see som eone t ake an hour of a senior m anager's t im e t o brief him on a problem and possibly recom m end a solut ion when t he present er doesn't have t he cost and backup inform at ion. The senior execut ive doesn't t hink she has enough inform at ion t o m ake a decision, so she put s t he m at t er off. What happens, however, is a very subt le charact erist ic of hum an nat ure. When you first hear about a scary problem , you are shocked and m ight well be m oved t o act ion. I f you do not act , however, you have been inoculat ed against t he problem . The next t im e you hear about it , you are less scared and less m oved t o act ion. Therefore, you need t o be prepared t o sell your proj ect t he first t im e! I de n t ify Opt ion s for Cou n t e r m e a su r e s I hat e doing t his! I know what I want ! I have done a m arket survey. Why should I have t o j ust ify t he product I have select ed? Well, if you didn't know t his before, I 'll let you in on a pot ent ial " got cha." The com m ercial int rusion- det ect ion syst em vendors aren't dum b! They are t rying hard t o reach t he CI Os and ot her t op execut ives of your organizat ion wit h non- t echnical, high- level issues- orient ed briefings. For inst ance, t he host - based com panies are pushing t he insider t hreat really hard. Therefore, if you com e m arching int o your CI O wit h your report and it doesn't m ent ion t he insider t hreat or consider host - based syst em s as opt ions, you m ight be one down inst ant ly.

Pe r son a l Fir e w a lls I f you are facing m anagem ent and t he issue of t he insider t hreat com es up, keep in m ind t hat int ernal firewall and personal firewall dat a can com e in very handy. I n som e sense, t hese serve as burglar alarm s and can alert you t o int ernal problem s. Before asking senior m anagem ent who is responsible for t he organizat ion's risk m anagem ent , funding, and support , it is a good idea t o know as m uch about t he probable risks as possible.

Take t he t im e t o list at least one opt ional approach and t o consider at least one alt ernat ive product for your recom m ended procurem ent s. You don't have t o pit ch t hese slides; in fact , you shouldn't pit ch t hese slides. But you do want t hem in case t he issue com es up. While you are at t his point , you need t o t ake a second for an int egrit y check. Are you t rying t o buy a t oy and help get t he j ob skills t o enhance your career or are you t rying t o secure your organizat ion? Have you really t aken t he t im e t o exam ine t hose firewall logs? I f t hey have good fidelit y, and you are honest ly m ore concerned about your organizat ion's securit y, perhaps you should consider spending t he t im e and m oney on a different aspect of your inform at ion- assurance archit ect ure. Cost - Be n e fit Ana lysis The cost aspect of t his sect ion is m ore im port ant t han t he benefit sect ion. This is where you give m anagem ent a warm , fuzzy feeling t hat you know how m uch t he recom m ended count erm easures are going t o cost . As a program m anager, when I hear som et hing t hat I know I want t o do, I really don't need a lot m ore inform at ion—j ust t ell m e what it will cost and when I can have it . Earlier, we t alked about t he case of having t o present t he whole package in five m inut es. I n t hat sit uat ion, you would use t hree slides: t he Execut ive Sum m ary, t he Cost Sum m ary, and t he Schedule.

W h y Cost - Be n e fit M a t t e r s Cost - benefit analysis doesn't sound sexy t o an int rusion analyst , but going t hrough t he exercise for even a one- page financial analysis is really wort h t he t im e. I used t o have an em ployee who was very bright , but she had an uncanny knack for com ing up wit h t he proj ect s guarant eed t o fail. Because she was so sm art , when she would suggest t hat we ought t o do som et hing, I would t hink, " Yeah, t hat m akes sense, let 's do it ." The next t hing I knew, it was crash and burn t im e, and I would look silly again in front of senior m anagem ent . Then what do you suppose happened? She cam e up wit h one of t hose, " I t hink we should…." My heart st art ed pounding, m y brain racing. I could feel m y st ress level go up. A wiser m anager would have sat down wit h her and t aught her t o calculat e t he cost , t he risk, and t he pot ent ial benefit s of a course of act ion. I t is easy aft er you have done it once. Not m e, t hough. I j ust rem inded her of t he failures, and in so doing, probably lost any chance of hearing anot her idea from a brilliant soft ware engineer. Not all benefit s are t angible and t hat is im port ant , but t his is where you want t o support your bang- for- t he- bucks slide. This is t he point where you list t he cost s. I n t he writ t en report , you should list all t he cost s; in a present at ion, you should present only t he sum m ary cost s. I f t here are quest ions, refer m anagem ent t o t he writ t en report .

Have you ever given a pit ch and had a m em ber of t he m anagem ent t eam challenge you? And j ust out of t he blue, t hey say, " I don't t hink t hat is going t o work." They don't even give a reason. They m ight have a double- digit I Q, but t he spot light is on you! This is where it really helps t o be prepared. Let m e m ake it plain for you: There is a bet t er- t han- even chance m anagem ent will ask t he following quest ions, and you will have t o give t he answers shown. Will an int rusion- det ect ion syst em : z

Act ually st op at t acks? No.

z

Det ect everyt hing? No.

z

Cost a significant am ount of m oney in equipm ent and salary? Yes.

So you see, you really do want t o be prepared! As backup m at erial, I st rongly recom m end you have at least one ALE ( annualized loss expect ancy) or SLE ( single loss expect ancy, as explained in Chapt er 12, "Writ ing TCPdum p Filt ers" ) calculat ion for what you t hink is t he biggest general t hreat against t he organizat ion. You should also have a couple exam ples of specific t hreat s against crown j ewels if possible. Select your cases carefully so t hat t hey support your choice of count erm easures. I f you end up needing t hese slides, your pit ch is in t rouble; so do a good j ob on t hem .

Bu sin e ss Pla n I am a passionat e, vision- driven person and I need t o be honest wit h you about som et hing. I am physically incapable of labeling anyt hing I writ e a " cost - benefit analysis." Let 's be careful here, 9 out of 10 consult ant s would agree t hat is t he correct t it le and form for what you should t ake t o m anagem ent for a final approval of a proj ect . I t is probably what decision- m aking m anagem ent expect s. So, aft er t elling you plainly t hat I am out side t he norm al and cust om ary in t his regard, please let m e share what I do. I produce a business plan, oft en it is only a couple of pages long, but it helps m e focus on t he issues. I t has t he sam e basic cont ent as a cost - benefit analysis. I deal wit h cost s, advant ages, t angibles, and int angibles, but t here is one added fact or: I t will help advance t he business. I t seem s t o m e t hat anyt hing you do should serve t wo purposes: I t should solve t he problem at hand, and it should advance t he business. The energy and capit al you invest should help your organizat ion achieve or m aint ain t he lead in your field. " Oh com e on St ephen," you m ight say, " int rusion det ect ion is an overhead funct ion; you can't m ake m oney on it ! " Wanna bet ? Baseball, I m ean int rusion det ect ion, has been very, very, good t o m e, and t o m any of m y friends as well. Don't short change yourself and skip learning t he m at erial in t his chapt er. Learn t o writ e a business plan or a cost - benefit analysis. This skill m ight lit erally pay off for you.

Pr oj e ct Sch e du le I have writ t en soft ware ( badly) for 15 years or so, but I have also m anaged som e pret t y skilled coders. I t ry t o get est im at es from t hem so t hat I can pass up m ilest one inform at ion on fut ure deliverables. Depending on t he person, I eit her double or t riple t heir est im at es. Soft ware people invariably t hink som et hing is a sim ple m at t er of a few lines of code unt il t hey get int o t he problem . The point I am t rying t o m ake is t hat m anagers develop a radar, a sixt h sense for bogus schedules. You are on t he next - t o- last slide of your present at ion, or next t o- last sect ion in your report . You do not want t o blow it here. I f you are not experienced at proj ect m anagem ent , here are som e got chas wit h fudge fact ors of it em s t hat will t ake longer t han you probably est im at ed: z

Procure anyt hing and everyt hing ( 2x)

z

Com pile and run any free soft ware ( 2x)

z

Get m anagem ent approval for any policy ( 5x)

z

I nst all t he soft ware and t est it ( 2x)

z

Get t he sensor t o work on a swit ched net work ( 5x)

z

Get t he analysis st at ion t o connect t o t he sensor t hrough t he firewall ( 3x)

z

Get clearance t o inst all host - based int rusion- det ect ion soft ware on product ion syst em s ( 5x)

z

Sweep your phone lines for vulnerabilit ies ( 5x)

z

Fix problem s you find wit h a net work vulnerabilit y sweep ( 5x)

The preceding list was part ly done in fun, but I also am serious. I f t hese it em s are part of your crit ical pat h, you m ight want t o give your schedule a second look. Follow - On St e ps At t his point , you have finished everyt hing we need t o do t o pit ch your solut ion. We have defined and quant ified bot h t he problem and t he solut ion wit h opt ions. What could possibly be lacking? Will inst alling t his solut ion solve all t he organizat ion's problem s? I f not , you should ident ify som e of t he next st eps. I f you are recom m ending a net work- based int rusion- det ect ion syst em , for inst ance, your next st eps m ight be as follows:

z z

Host - based perim et er defenses for crit ical syst em s Dat abase for t rend analysis, especially wit h t he em ergence of ent erprise securit y m odules t hat allow you t o consider dat a fr om NI D, HI D, firewall, rout er, and syst em log files

z

I nt ernal net work- based I DSs for high- value locat ions

z

Organizat ion- wide host - based perim et er defense deploym ent

Each of t hese st eps should include a high- level est im at e for t im efram e and cost . Taking t he t im e t o show t he next st eps helps m anagem ent in t wo im port ant ways. I t shows you have t echnical vision—t hat t here really is a well t hought out plan. Also t he budget planning cycle for capit al purchases at m any organizat ions is done several years in advance. By present ing t he follow - on st eps, financial planners can use your inform at ion as budget " wedges" for fut ure years.

Re pe a t t h e Ex e cu t ive Su m m a r y You know t he drill. Tell t hem what you are going t o t ell t hem , t ell it t o t hem , and t hen t ell t hem what you t old t hem . This is an excellent t im e t o repeat your Execut ive Sum m ary point s.

Su m m a r y I hope t his chapt er and t his book have been helpful t o you. This chapt er was t ailored for securit y professionals who don't have an int rusion- det ect ion capabilit y, want t o upgrade t heir capabilit y, or have t hese j ob posit ions under scrut iny. I n m uch of t he book, we t ry t o give you a bit of insight int o t he enem y. I n t his chapt er, we have t ried t o give you insight int o m anagem ent and business processes. The m ost im port ant t hing t o keep in m ind, bot h for yourself and when you brief m anagem ent , is t hat int rusion det ect ion should be an int egral part of your organizat ion's inform at ion- assurance st rat egy. I n fact , int rusion det ect ion should be a part of every nat ion's inform at ion- assurance st rat egy. The event s of t his com ing year wit h m assive I RC bot driven dist ribut ed denial- of- service at t acks, SNMP/ ASN.1 exploit s, and polym orphic at t acks will prove t his t o be t rue. You don't need an I DS t o det ect a DDoS at t ack, but it will help you find t he com prom ised host s before t hey can be used t o hurt som eone. Now, let us t ake som e t im e t o discuss t he fut ure of int rusion det ect ion in our final chapt er in t his book.

Ch a pt e r 2 0 . Fu t u r e D ir e ct ion s

Prognost icat ion is dangerous. Have you seen t he st udies on t he accuracy of newspaper and t abloid predict ions? How will we do bet t er? I t is t im e t o discuss t he leading edge, t he em erging t ools and t rends in int rusion det ect ion. I am asked t o speak on t he fut ure of various inform at ion assurance t opics a couple t im es a year and t ry t o st ay abreast of t rends, hold focus groups, and so fort h. None of t hat ensures t hat I will be right about anyt hing; so, consider what you read in t his chapt er wit h care. Wit h t hat , here is m y read on t he fut ure for int rusion det ect ion. I n t erm s of broad t rends, we will discuss t he em erging t hreat , cyber- t errorism , t he ease by which at t ackers are able t o inst all and run m alicious code on our syst em s, t he im provem ent s in reconnaissance and t arget ing, skills versus t ools, defense in dept h, and large- scale int rusion det ect ion. Finally, we'll close wit h som e short t akes on em erging t rends.

I n cr e a sin g Th r e a t One of t he drivers t hat fuels t he cont inued int erest in int rusion det ect ion is t he increasing t hreat . The progress in at t acker t ools over t he past year has been incredible. I am not t alking about Code Red so m uch as Leaves and t he I RC bot ( robot program s) net s t hat reached a significant level of sophist icat ion in m id2001. At t ackers have t he firepower t o knock alm ost any sit e off t he I nt ernet . They can coordinat e a fast scan, blowing t hrough half of a class B in about five m inut es from 2,500 or so discret e source host s. They can also scan very slowly, m odulat ing t he t echnique t o be alm ost undet ect able. Many of t hese at t ackers are also securit y pract it ioners by day, a dist urbing fact , and t hey are not planning t o st op writ ing at t ack code. Cybe r - Te r r or ism " Have you seen any evidence of increasing at t acks, anyt hing significant ?" No less

t han five of m y friends t hat work for t he governm ent had asked m e t hat quest ion by noon on 9/ 11/ 2001. Suddenly, we st art ed hearing about cyber- t errorism and, wit h Execut ive Order 13231 filed aft er t he at t ack, we see t he US Governm ent preparing defensive m echanism s against cyber- t errorism . Alt hough we have t ried t o det ail t he increasing t hreat , and t o be sure t here is a lot of firepower out t here, I do not see any evidence t hat cyber- based t errorism is a near- t erm t hreat . There are hint s and glim m erings of it , but t he em phasis of t errorism seem s t o rem ain fixed on bom bs and guns. I s cyber- t errorism a credible t hreat ? I n som e sense, it has t o be. Much of t he infrast ruct ure is com put er cont rolled, and t he com put ers are cert ainly vulnerable. The m ain t hing t hat seem s t o be holding cyber- based t errorism back seem s t o be t he at t acker's apparent lack of skill and m ot ivat ion. I n ot her words, t he com m it t ed t errorist s st ill seem t o prefer bom bs and guns t o lapt ops for now. Wit h t hat said, we do need t o consider t he im plicat ions of t he large at t ack net works t hat have been form ed in t he past year. One reason we have not seen m ore dam age is t hat m any of t he people involved in creat ing t hese at t ack net works are not really m alevolent . An int erest ing t rend t hat is as t rue t oday as it was when I first learned about it in 1997 is t hat a m ain t hem e of all t his advanced denial of service is I nt ernet Relay Chat ( I RC) . Groups of hackers fight ing for cont rol of I RC chat room s developed t he denial- of- service t ools. As long as people were cont ent t o clobber I RC servers, who cared? Now t he genie is out of t he bot t le and it cannot be put back. I t is int erest ing t hat t he lat est at t ack net works are I RC bot s, but t hey are cert ainly not const rained t o I RC t arget s. I f a group bent on t errorism was t o gain cont rol of one of t hese net works, it could cert ainly do significant dam age, especially financially. I f you could keep t he t op t en I nt ernet businesses offline for a week, what would t he pot ent ial financial dam age be? I t is m ore t han j ust t he lost revenue; it would include t he weakened st at e of t he com panies and pot ent ially a serious effect on t he st ock m arket , especially t he t echnology rich NASDAQ exchange. The bot t om line on t errorism , cyber or not , is t hat your or ganizat ion should have a cont ingency plan. Right aft er 9/ 11, t here was a bit of concern about creat ing and updat ing business cont inuit y plans, but it seem ed t o pass quickly, even while t he sit e of t he World Trade Cent er was st ill sm oking. The m ain t hing is t o m ake sure you have an alt ernat ive way of doing business in case t he net infrast ruct ure get s severely pert urbed at som e point . La r ge - Sca le Com pr om ise Troj an horses, logic bom bs, and soft ware vulnerabilit ies are incredibly ram pant . The bad news is t hat it is essent ially im possible t o secure m odern operat ing syst em s. One of t he reasons for t his is t heir com plexit y. Take a look at your act ive processes, ps –ax or ps –ef on UNI X and Ct rl+ Alt + Del on Window s. Ask yourself if you would recognize if som et hing changed on anyt hing t hat is shown. These are high- level list ings, not t he funct ion calls and .dlls t hem selves. I f som eone were

able t o plant a m alicious rout ine on one of your syst em s, you would probably not be able t o find it except wit h a t ool like ant i- virus soft ware. So how do t hese backdoors and such get plant ed on your syst em s? A huge vect or for Windows syst em s in t he past t wo years has been browser relat ed problem s. A num ber of vulnerabilit ies in Microsoft 's I nt ernet Explorer have been report ed t hat allow at t ackers t o run arbit rary program s on syst em s when t he browser downloads web pages wit h specially form at t ed st rings. This is on t op of t he previous t rend of creat ing at t acks based on vulnerabilit ies in t he Out look m ail program . Grant ed, t hese at t acks are at t he bot t om of t he food chain in som e sense—PCs—m any of which are on dial up connect ions and cannot do t hat m uch dam age; but j ust as m any are inside governm ent facilit ies, corporat ions, educat ional inst it ut ions, and hom es wit h broadband connect ivit y. On UNI X syst em s, a variet y of buffer overflows have been found and exploit ed t hat allow at t ackers t o accom plish t he sam e t hing. I n addit ion t o t he t echniques t hat at t ackers use t o break int o syst em s, t hey are also becom ing m ore adept at finding syst em s t o break int o. I m pr ove d Ta r ge t in g I n t his book, you have learned a lot about t he various reconnaissance t echniques at t ackers use. Mult iple organizat ions are involved in I nt ernet m apping effort s. Som e of t he aspect s of advanced t arget ing include t he following: z

z

z

Techniques t o m axim ize result s using broadcast packet s when possible. I f a sit e allows broadcast packet s t o ent er it s net work from t he I nt ernet , t his allows t he at t ackers t o get significant result s wit h a fairly low num ber of st im ulus packet s. Scanning is act ually fairly slow going; t his is t he reason nm ap and ot her t ools default t o an echo request first . I f t hey get a reply, t hey invest in scanning for open port s and prot ocols. Avoidance of dangerous I P address ranges, based on list s of honeypot s and sit es t hat are known t o be alert and act ive in report ing t o CI RTs and law enforcem ent . Sharing reconnaissance dat a bet ween scanning organizat ions m inim izes t he foot print . I f t wo groups have different t echniques and t hey share t he result s, it is harder t o det ect t hem in act ion, especially if t hey bot h use dist ribut ed scanning.

Because t he reconnaissance has been going on for a long t im e, we are now seeing t he result s of long- t erm m apping effort s. When you see a few probes, t hey m ight be validat ing t hat t he sit e m ap t he at t ackers hold is st ill fairly up- t o- dat e. As new vulnerabilit ies are found, t he at t ackers will have t he capabilit y t o launch precision at t acks. H ow t h e Thr e a t W ill Be M a n ife st e d

The fact t hat syst em s are vulnerable and at t ackers are perfect ing t heir t echniques for finding vulnerable syst em s is not news. What changed in lat e 2001 and early 2002 was t he scale. Large- scale, successful at t acks such as Leaves SubSeven scans, Code Red and nim da against I I S, and t he SNMP/ ASN.1 and Apache PHP at t acks in early 2002, left at t ackers wit h net works of t housands and t housands of com prom ised zom bie syst em s, and t hey had prim it ive, but workable com m and and cont rol syst em s t o m anage t hese net works. This m uch firepower has a couple of uses.You can t hreat en t o blow alm ost any sit e off t he I nt ernet . By February 2002, t wo years aft er t he original dist ribut ed denialof- service ( DDoS) at t acks against high- end web sit es like CNN and Yahoo, at t ackers were going aft er I SPs. I n February, when t he SANS I nst it ut e was funding a webcast about a free new Cisco rout er securit y configurat ion t ool, t he I SP st ream ing t he webcast , Digit al I sland, report ed it was hit wit h a denial- of- service at t ack disrupt ing t he webcast . And, t he at t ackers cont inued t o explore t heir firepower. As March of 2002 opened, we were seeing t est at t acks where sit es were knocked off t he I nt ernet by doing a t racerout e, det erm ining t he rout ers t he sit e needed t o connect t o t he I nt ernet and leveling t hem . They were also beginning t o experim ent wit h TCP port 179, BGP. As I writ e t his, I cannot know t he fut ure, but from t he close of February 2002, m y way- out - on- a- lim b guesses would be t hat t wo t hings seem likely: z

z

The at t ackers are not going t o be able t o resist t est ing out t his firepower. Som e will j ust be in it for t he m oney and will t ry ext ort ion, t hreat ening t o disrupt e- business sit es like eBay or Am azon. Ot hers will be m ore int erest ed in a grand st unt , probably against t he t wo exposed services on t he I nt ernet , rout ing and DNS; and if you can t ake out rout ing, DNS falls nat urally. Our best analysis says you cannot t ake down t he ent ire I nt ernet , because it is m ade up of t oo m any independent part s. The governm ent is going t o do t he only t hing it can do—m ake it a serious crim inal penalt y t o run t hese kinds of at t acks. This has already st art ed wit h t he laws t hat passed aft er 9/ 11, but if t he at t ackers do pull a bold st unt , lawm akers around t he globe will probably have t o respond.

This is not t o say t hat all is gloom and doom —far from it . The t hreat m ight be reaching it s highest point in a few m ont hs, but t here appears t o be som e nat ural lim it s t o t he growt h.

D e fe n din g Aga in st t h e Th r e a t There are count erm easures and lim it s t o t he increasing t hreat . I n t his sect ion, we will first discuss t he nat ural lim it s and t hen consider t he developm ent of skills and t ools for defenders. Also, t he com m unit y is m aking progress in underst anding and im plem ent ing defense in dept h. We are also deploying int rusion det ect ion in a large- scale m ode t o be able t o see t he t rends quickly. The good news is t hey are

about ready t o hit som e lim it s t hat ought t o slow t hem down a bit . What lim it s? z

z

z

z

The current DDoS t ype at t ack t ools like Leaves and lit m us have t heir com m and and cont rol via I nt ernet Relay Chat . This is bot h t heir st rengt h and weakness. At som e point , t he com m unit y is going t o wise up and st art blocking t his t ype of prot ocol. There are count erm easures t hat t he at t ackers can and will t ake, but t hese can and will be cont ained. A large num ber of scans depend on public addresses. Every t im e an organizat ion swit ches t o a NAT and privat e addresses, it becom es j ust a lit t le bit harder for at t ackers. Many of t he at t ack net works we are current ly facing are a result of t he Leaves ( via SubSeven) , Code Red, and SNMP/ ASN.1 bonanzas of m id- 2001 and early 2002. OK, t his is where I go so far out on a lim b. I t isn't funny, but a large num ber of t hese m achines are Windows, and lat ely t here has been som e evidence t hat Microsoft really cares. I t hink t hat seeing 180,000 I I S web servers swit ch t o ( m ost ly) Apache in t he m ont hs aft er Code Red really got t heir at t ent ion. Follow t he m oney! The m oney is prim arily going int o t he defensive side of t he house. The at t acker com m unit y is dem onst rat ing a lot of ingenuit y, but as lower cost , easy- t o- configure securit y appliances com e on t o t he m arket , and securit y t raining t hat really works becom es available, t here will be less low hanging fruit . At t acking will becom e less fun and less com m on, and it will be easier t o shun sit es t hat do not st op bad behavior.

Money really is t he int erest ing quest ion. I t seem s logical t o assum e t hat if you are invest ing in securit y, it will m ake a difference. However, February 13, 2002, t he Unit ed St at es Office of Managem ent and Budget ( OMB) released a report 2002- 05, ht t p: / / www.whit ehouse.gov/ om b/ inforeg/ fy01securit yact report .pdf, on federal inform at ion securit y. The report , t o no one's surprise, out lined a num ber of short com ings including t he following: z

I nadequat e senior m anagem ent at t ent ion

z

I neffect ive securit y educat ion and awareness

z

I m proper securit y pract ices by out side cont ract ors

z

I nadequat e det ect ion and report ing of vulnerabilit ies

However, t he m ost significant finding in t he report was t here was no det ect able correlat ion bet ween t he am ount of m oney invest ed in inform at ion securit y and t he result s. Furt her, t hey did not even consider t he im port ance of good t ools ot her t han in som e discussion about capit al expendit ure. I n t he near fut ure, if we are able t o invest t he m oney we have available wisely on skills developm ent and apply

som e good process when deciding which t ools t o purchase, I t hink we will m ake som e significant forward progress. Sk ills Ve r su s Tools The int erest in t he t opic of int rusion det ect ion is st ill on t he rise. SANS offered t he first I nt rusion Det ect ion I m m ersion Curriculum in March 2000 and not only was it sold out , would- be analyst s really t urned t o som e high- end social engineering t rying t o get a seat . Today, we offer t he current hands- on, six- day int rusiondet ect ion t rack som ewhere in t he world every week. That is a dem onst rat ion of t he dem and, and it is fueled by a desire t o learn how t o do int rusion det ect ion. Would- be analyst s are learning all t he t hings t hat you learned in t his book: bit m asking, basic analysis skills, and how t o writ e filt ers, all t he at om ic skills t hat prepare one t o do int rusion det ect ion. At t he sam e t im e, com panies are working t o build bet t er and bet t er t ools. I t is fairly clear at t his point t hat you cannot build an I DS t hat does not require a skilled operat or. The one com m ercial com pany t hat t ried t o m ake an easy- t o- use GUI as num ber one priorit y get s a lot of sales, but m any com panies t hat buy t heir product s are replacing t hem a year lat er. As we m ove forward, it looks like t he balance will swing t o t ools designed t o allow an analyst t o use her skills. An a lyst s Sk ill Se t

I nt rusion- det ect ion syst em s have t he sam e problem as ant i- virus soft ware: New at t acks are not det ect ed because t here is no signat ure for t hem . But t he problem is worse because so few signat ures have been defined for NI DS, st ill less t han 2,000 decent signat ures, com pared wit h t he 30,000 or m ore for ant ivirus. There are nat ural lim it at ions of signat ure- based net work int rusion- det ect ion syst em s, and t o be effect ive, I recom m end coping st rat egies like a box recording all t raffic. That way, it is possible t o go back aft er t he NI D alert s and exam ine t he st im ulus t hat lead t o t he act ivit y report ed by t he NI D. I also like t o keep a cache of at least several days of raw dat a, so if I get lucky and det ect som et hing I have a way of checking t o see if t here was previous act ivit y. Today, an analyst needs t he abilit y t o writ e a filt er t o run t hese t ypes of searches. I n t he fut ure, as console solut ions are fielded, it m ight be possible t o do m uch of t his wit h canned searches, but even wit h relat ional dat abases, an analyst m ight have t o be able t o describe t he search he needs in SQL. Com panies are realizing t hey need skilled people. Even in t he econom ic downt urn of 2001, SANS was st ill running class aft er class and m ost of t he classes were full. Com panies are even requiring cert ificat ion when t hey are looking t o hire. At first , t his was laudable, but depressing, " I DS Analyst needed, m ust be able t o writ e I DS rules, int erpret hex, and hold a current CI SSP cert ificat ion." Arrrg, please do not int erpret t his as a slam against t he Cert ified I nform at ion Syst em Securit y Professions ( CI SSP) , but t he CI SSP cert ainly does not cert ify a person t o run an I DS or configure a firewall or t o do any ot her t echnical t ask. However, com panies

are learning fast , and recent ly t he Foot e survey echoed t he earlier Gart ner survey t hat showed Global I nform at ion Assurance Cert ificat ions ( GI AC) cert ificat ions cont ribut ed t o a higher salary and a higher chance of em ploym ent . The t ools are get t ing bet t er, but for t he next few years at least —and I expect forever—not hing replaces a skilled analyst . The rapid em ergence of personal firewalls is already a m aj or defensive force, alt hough we need t o find easy ways t o harness t his dat a. They range from t he load- and- forget Sym ant ec I nt ernet Securit y, which com bines ant i- virus wit h light weight prot ect ion and det ect ion, t o BlackI ce, which can log packet s for analysis. These folks have essent ially solved t hat old host - based problem , t he effort of deploym ent ! Securit y conscious em ployees t ake it on t hem selves t o inst all personal firewalls at work and at hom e; if t hey bot her report ing, t hey becom e valuable sensor input s. There are aut om at ed t ools like Dshield, ht t p: / / www.dshield.org/ , t o t ake t he dat a from t hese syst em s and exam ine it for t rend inform at ion. Net work- based NI DS are st ill being deployed at a good rat e as well. I t is easier t o get som eone t o st ick t wo boxes on her net work t han t o get her t o even t hink about adding a nonproduct ion, cycle- consum ing, soft ware layer t o all t he host s in her net work. When I analyze what it t akes t o do a really effect ive j ob of int rusion det ect ion, t he advant ages of personal firewalls on t he host com put ers of securit y- aware em ployees are enorm ous and really add t o t he net work - based dat a. So, it is no surprise t hat we are com ing t o t he age of t he console, t he dat abase driven syst em t hat norm alizes NI D dat a wit h firewall, personal firewall, ant i- virus, and pot ent ially ot her dat a such as syslog report s, and gives us a bet t er view of what is going on in our net works defensively t han we have ever had. I m pr ove d Tools

These new consoles have a num ber of form s. Som e of t hem are advanced log wat chers like Big Brot her ( www.bb4.com ) and Net I Q ( www.net iq.com ) ; cont ent analysis t ools like Silent Runner ( www.silent runner.com ) ; and correlat ion engines t ools like net Forensics ( www.net forensics.com ) , I SS Sit eProt ect or ( www.iss.net ) , and I nt ellit act ics NSM ( www.int ellit act ics.com ) . This is j ust t he t ip of t he iceberg. I know of a num ber of com panies t hat are racing t o unveil product s including t he Sourcefire OpenSnort console ( www.sourcefire.com ) t hat uses t he high perform ance dat abase t ool nam ed barnyard t hat was developed by Andrew Baker. As t hey st art t o really com pet e and we go t hrough t he rounds of reviews and bakeoffs, we should end up wit h som e very usable t ools. The good news is t hat t here are fact ors t hat should serve t o slow t he rat e of im provem ent for at t acker t ools. Com panies have been buying t ools all along, but t hey are not get t ing t he kind of qualit y t hey deserve for t he m oney t hey spend. We m ent ioned a com m ercial I DS earlier t hat m any com panies, a year aft er t hey inst all it , are replacing. What is wrong wit h t his pict ure? Obviously, t he com pany has a world class m arket ing program , but how have we as a com m unit y allowed a sensor t hat doesn't even record t he TCP code bit s t o exist for so m any years, t o wast e so m any

organizat ions' t im e and m oney? The good news is it looks like t he next release will be credible, but we need t o dem and t ools t hat work. The com pet it ion in t he net work int rusion det ect ion arena is funny. You don't have t o be an indust ry insider t o quickly realize t hat Ron Gula wit h Dragon, Robert Graham wit h BlackI ce, now RealSecure and Mart y Roesch wit h Snort are not j ust brilliant , t hey are really invest ed m ent ally and em ot ionally in t heir product s. I n t he background is t he very capable Kevin Zeise on t he Cisco t eam . He m ight not be as visible as t he ot hers in t he field, but he is t he kind of guy t hat runs four m iles in t he m orning, eat s t wo pieces of key lim e pie for breakfast , rolls out a new product line by lunch, and t hen saves t he world from t he lat est cyber cat ast rophe before ret iring for t he evening. He is fully capable of running wit h t he I DS pack. The various m ailing list and conference bat t les are great ent ert ainm ent , but t hey also serve a purpose. I n a world of m arket ing and lies, t hese t hree folks, at least for now, are seriously com m it t ed t o building t he best t ool t hey can. Who will win? I t isn't som et hing one person can do, it will be t he best t eam . So in t he spirit of predict ing t he fut ure, back out ont o a lim b I go: z

z

z

Ent erasys is having som e problem s right now wit h t he SEC and has had cash flow problem s for a while. St ock opt ions aren't as m uch of a m ot ivat or when you drop from 11 t o 4 in a single day, so wat ch for som e bailout s of brainy engineers t hat want anot her shot at m aking a m illion dollars. I like Dragon and part icularly like som e of t heir net work gear but don't t hink I want in for m ore t han a 100 shares—t oo likely t o becom e wallpaper. So, I t hink Dragon could have been a cont ender, but t he SEC probably banged t hem t oo hard for t hem t o com pet e in t his neck- and- neck field. I SS and Robert Graham have t o be t he odds- on favorit e in early 2002. The I SS m anagem ent t eam is good, t he m arket ing t eam bet t er, and t he X- Force side of t he house has been solid for years. There were a lot of t hings I liked about BlackI ce t hat Robert could build int o RealSecure in his sleep. There is no doubt in m y m ind t hat , short of burning out or get t ing hit by a bus, Robert will produce a sensor t o be reckoned wit h. The quest ion is whet her t hey will be able t o build or int egrat e wit h a great console. As I writ e t his, Sit eProt ect or is j ust t oo new t o be evaluat ed, but it has t o work for I SS t o shine because t hey have bet heavily on ent ering t he m anaged services m arket , and t hey need t his t ool t o do it . My predict ion is t hat t he answer will com e down t o t he skills versus t ools ar gum ent . I f t hey build t heir console so t hat it helps a skilled worker be all she can be, I t hink I SS can win against everyone except Cisco. I f t hey build a console t hat has a philosophy of " sit here and if you see a red t riangle, call m e," I t hink t hey will lose any chance at m arket credibilit y. Cisco developed a st rat egy years ago of m oving int rusion det ect ion int o t he net work. The Cat alyst 6000 and t he Policy Feat ure Card is going t o give TopLayer, t he darling of t he got t a go fast int rusion analyst , a serious run for

t he m oney. This call is a no brainer. High- end sit es wit h high- value asset s are going t o go Cisco. My m oney is where m y m out h is t oo; when t heir st ock dips, we pick up anot her chunk whenever we can. z

Sourcefire, led by Mart y Roesch, j ust received t wo m illion dollars in round one vent ure capit al. I need t o be honest ; I am hardly obj ect ive. When t he com pany st art ed and I was given an opport unit y t o fund t he st art up, I j um ped at it . So read what I say wit h m ore t han a bit of salt and I will t ry t o st ick t o t he m ain issues. The fact s are sim ple: Snort is t he m ost widely deployed sensor on t he planet and t he Snort ruleset and language are t he m ost com m only read and writ t en. This is wit hout debat e. However, t hat is free Snort , and I have wat ched from t he sidelines as m y friend Gene Kim and Tripwire have t ried t o m ake t he t ransit ion from free soft ware t o com m ercialware and it is not an easy t ask. Moreover, Mart y is not t he only one wit h t he idea of com m ercializing Snort . My guess is t hat he has ent ered t he m arket at t he best of t im es. At a t im e when it is harder and harder t o find a decent st ock value, I SS and Ent erasys have plum m et ed, reducing t heir value, t his is now a great opport unit y for t he t iny Sourcefire.

The bot t om line, m y guess, is t hat by t he t im e t his book get s int o your hands, Cisco and Sourcefire will be st ronger, I SS holding it s own, Ent erasys on t he ropes, and NFR, no closer t o an I PO t han t hey ever were. Will Tippingpoint , t he new Swiss arm y knife of inform at ion securit y, even be in t he running? Probably not , it is m ost likely st ill a year or t wo before users will be ready for int egrat ed firewalls/ NI Ds, but we will see. The fact t hat cannot be argued is t hat t he significant com pet it ion and innovat ion is driving t he bar up and we all win because of t hat . One reason t hat I am so focused on t his new generat ion of consoles is t hey are t he foundat ion for analyst s t o m aint ain sit uat ional awareness and one of t he m ost im port ant t ools for building act ive defense in dept h.

D e fe n se in D e pt h Milit ary hist ory t eaches us t o never rely on a single defensive line or t echnique. We have t ried t o t each you not t o rely on your NI D alone. When a filt er fires, it m ight be necessary t o det erm ine why it fired and t he net work act ivit y t hat preceded it . We have been t rying t o t each you t o rely on your abilit y t o decode a packet in addit ion t o using your NI D as a t ool. This is one sm all exam ple of defense in dept h. The firewall serves as an effect ive noise filt er, st opping m any at t acks before t hey can ent er your net work. Wit hin your int ernal net , t he rout er or swit ch can be configured t o wat ch for signs of int rusion or fraud. When a det ect occurs, t he swit ch eit her can block t he session and seal off t he host or j ust send a silent alarm . You can im prove your m odel furt her by adding t he host - based layer of defense. Here, you can det ect t he insider wit h a legit im at e login ( whet her or not it is really his) accessing files he shouldn't . Toss in a couple m ore net work- based

int rusion- det ect ion syst em s, including a few st ealt hy ones, and you have an archit ect ure sufficient t o count er t he increasing t hreat . Sadly, t his archit ect ure seem s t o be m ore likely found in a Jet sons cart oon t han real life. So what is possible t oday and in t he near fut ure t o im plem ent defense in dept h? The five perim et er rules of t he road are t he first st eps, t he ones you should put int o pract ice t oday if you are not already doing t hem . Please do not st art wit h a lot of t alk about a crunchy perim et er and a soft chewy inside; we will get t here soon enough. The five rules are all covered in t he book and t he appendix, but t his is t he final chapt er and needs t o be t he sum m ary chapt er as well as a discussion on t he fut ure of int rusion det ect ion. The five rules of t he road are as follows: z

z

z

z

z

Squelch all out going I CMP error unreachable m essages. You m ight choose t o st op ot her out going I CMP error m essages, but do not fail t o st op t hese. Doing t his will reduce your sit e's vulnerabilit y t o reconnaissance. Split horizon DNS. You m ight call t his by a different nam e, but t he concept is sim ple. The DNS server( s) t hat can be reached from t he out side should only know about a few of your host s including your m ail server, web server, and you fill in t he rest of t he blanks. Ot herwise, t his DNS server can be used for reconnaissance against your sit e. Proxy when possible. Not only are proxies available on your firewall, but t hey can also be put bet ween t he I nt ernet and your I nt ernet facing devices. Net work Address Translat ion ( NAT) . I f your sit e can find t he backbone t o give up t hose evil public addresses and m ove t o privat e addresses, you will inst ant ly find a t enfold benefit in your resist ance t o at t ack. I m plem ent aut o- response. Yes, really. The ant i- j unk m ail world has been doing it for years. The Rapt or firewall wit h it s act ive defense and BackOfficer Friendly haven't m elt ed down t he world. There is a place for aut o- response and you need t o get in t he gam e ( as t hey say in t he m ovie Zorro) , as safely as possible.

Defense in dept h doesn't st op wit h t he perim et er, of course. I t includes configurat ion m anagem ent , personal firewalls, ant i- virus, cont ent scanning at t he perim et er, operat ing syst em pat ches, and an act ive vulnerabilit y scanning program . La r ge - Sca le I n t r u sion D e t e ct ion One of t he m ost fascinat ing t rends in 2001 was t he em ergence of t hree large- scale int rusion det ect ion effort s: Aris by Securit yFocus.com , MyNet Wat chm an ( www.m ynet wat chm an.com ) , and Dshield ( www.dshield.org) . Each of t hese works by providing report ing soft ware t o hundreds or even t housands of client s. These client s range from Check Point firewalls and Linksys cable rout ers t o

personal firewalls. The dat a is sent t o a cent ral sit e t hat allows it t o be exam ined for t rends. The aggregat ion of t his m uch dat a from all over t he world is a powerful t ool. Dshield, for inst ance, was adding about six m illion records per week. Alt hough t here are significant issues wit h norm alizat ion, wit hin t he first year of Dshield's operat ion, t he t echnology was used t o discover t he Ram en, Lion, and Leaves worm s. For inst ance, t he CERT advisory on widespread vulnerabilit ies wit h SNMP and ASN.1 was released on February 12, 2002, and you could see t he increase in scanning as t he m ont h progressed, as shown in Figure 20.1. Figu r e 2 0 .1 . D sh ie ld da t a plot .

These are new im plem ent at ions, and t he com m unit y is st ill t rying t o learn how t o m ake t he best use of t he t ools. Dist ribut ed int rusion det ect ion syst em s like Dshield is such a profoundly significant concept t hat a num ber of people I t alked wit h found it hard t o underst and why it hadn't been done earlier. One of t he reasons is t hat a subt le shift in at t it ude t ook place aft er t he t urn of t he cent ury, and people were willing t o share dat a.

Sh a r in g I asked t he I ncident s.org com m unit y if anyone want ed t o cont ribut e a sidebar for t he second edit ion of t he book. I t is no less t rue t oday, so we will keep it in t his edit ion. The following was subm it t ed by Richard

Bej t lich, a skilled int rusion analyst , and I decided t o place it here prim arily because of t he fourt h quest ion below. " I m ake opt im um use of m y net work int rusion det ect ion syst em ( NI DS) by asking four quest ions: z

What could cause suspicious t raffic t o be generat ed?

z

What event s could m y NI DS m iss?

z

How does real I nt ernet behavior differ from t ext book descript ions?

z

Should I share event s wit h t he securit y com m unit y?

The first quest ion suggest s t hat packet s can be forged, m anipulat ed, and unwillingly solicit ed, in addit ion t o being rout ed direct ly. The second quest ion requires m e t o underst and m y NI DS' lim it at ions, and rem em ber it m ight not explain or even capt ure every relat ed packet . The t hird quest ion im plies t hat t raffic not m at ching t he norm s of RFCs or t echnical st udies is not always m alicious. The last quest ion encourages int rusion det ect ors t o share t heir quest ions and discoveries wit h t he securit y com m unit y, whet her t hrough www.sans.org or forum s like t he securityfocus.com 1

I ncident s list ." 1

Richard Bej t lich

I n addit ion t o det ect ion, t hese large- scale int rusion det ect ion net works also play a crucial role in response. As t hey collect dat a and t he inform at ion passes a cert ain t hreshold, t hey can creat e aut om at ed or sem i- aut om at ed report s and send t hem t o t he responsible part y for an I P address. For inst ance, on February 28, 2002, I P address 217.128.207.17 from t he abo.wanadoo.fr dom ain was det ect ed sending 33,995 packet s. Now, t hat cert ainly warrant s sending a not e, t hough sending a not e t o Wanadoo asking t hem t o quit ft p scanning is a bit like sending a not e t o Bin Laden asking him t o st op t errorism —at best , t hey don't care. However, m any people do care, and t he not e from Dshield m ight be t he first hint a syst em adm inist rat or get s t o help him realize he has a problem . Below is a not e from anot her sat isfied cust om er: " Thank you for t he not ificat ion of illicit act ivit y com ing from a com put er in t he Universit y of XXXXX XXXXXX dom ain. This was a facult y m em ber's com put er t hat was found t o have t he " m um m y" virus when t he eSafe virus scanner was ran on t he com put er. We have at t em pt ed t o disinfect t his com put er t o prevent t he unaut horized int rusions t o your and ot her net works. Again t hanks for t he not ificat ion; and if t here is anyt hing else we can do, please let m e know."

By t he way, I am a bit skept ical about t he part iculars in t he report . The m um m y virus is an MS- DOS Jerusalem variant , so t his sounds like an excuse t o cover som e m ischief, but as long as t he behavior changes, it is anot her win for t hese new defense syst em s. To dat e, only Aris has a business m odel t o support what it is doing, so it is not clear t hat t hese first im plem ent at ions of large- scale int rusion det ect ion will survive long t erm . I cert ainly hope t hey are an em erging t rend. I would like t o close t he chapt er and t he book wit h a quick review of t he ant i- virus indust ry, a discussion of hardware- based and program - based int rusion det ect ion, and finally, som e of t he changes in audit ing.

Em e r gin g Te ch n iqu e s Current int rusion- det ect ion syst em s are fairly lim it ed. Net work- based syst em s are not well suit ed t o det ect t he insider t hreat , m obile code, int elligence- gat hering viruses, m odem - based at t acks, or runs along t he t rust m odel. Host - based syst em s can det ect t hese at t acks, but t hey suffer from t wo big problem s: t he cost of deploym ent and t he syst em overhead " t ax." There is a lot of m oney t o be m ade by t he com pany t hat can build and m arket t he bet t er m ouset rap. The ent erprise securit y consoles we have discussed are one t echnology poised t o collect som e of t his m oney—aft er all, what securit y guy is not going t o want a cockpit ? Curiously, t he m arket sect or t hat appears t o have snat ched defeat from t he j aws of vict ory is t he ant i- virus arena. Vir u s I ndu st r y Re visit e d I have wat ched in am azem ent as NAI and Sym ant ec, t wo com panies in exact ly t he right place t o t ake advant age of t he gap bet ween t he increasing t hreat and exist ing response, have failed t o t ake t ot al cont rol of t he host - based int rusion det ect ion m arket . Even if ant i- virus m akers do not want anyt hing t o do wit h t he int rusion- det ect ion m arket sect or, t hey are already int ersect ing wit h it . These Troj ans all have a net work signat ure, SubSeven, and net bus and all t he rest . Ant ivirus com panies can det ect all of t hese and rem ove t hem as well! Well, m aybe not . The first clue I had t hat ant i- virus could be evaded was when one of m y st udent s realized he had accident ally downloaded a Troj an when he saw " not epad.exe" go by aft er having clicked on a download page. Aft er som e invest igat ion, he det erm ined it was QAZ. And yet , his ant i- virus didn't pick it up. But how is t his possible wit h a well known Troj an? Well, it t urns out t hat t he at t acker com m unit y can " pack" t he Troj an wit h any num ber of t ools. For m ore inform at ion on t his, go t o ht t p: / / rr.sans.org/ m alicious/ t roj an_war.php. However, do not count out t he ant i- virus indust ry. I t can det ect t he work of m any of t he m ore popular packers and cert ainly can det ect t he Troj an when it becom es act ive on t he net work if you also have a personal firewall packaged wit h your ant ivirus. Well, you can if t he m alicious code doesn't disable t he firewall and/ or ant ivirus soft ware as one of it s first orders of business, but t he com panies are working on defending against t his as well.

Sym ant ec's I nt ernet Securit y product t hat com bines ant i- virus wit h a personal firewall is not a bad product , but it could have been a killer applicat ion. Ant i- virus com panies are poised t o be t he 800- pound gorillas in int rusion det ect ion. An ant ivirus com pany could excel in t his indust ry because of t he following eight reasons: z z

z

z

z

z

z

z

No securit y t ool has bet t er deskt op penet rat ion t han ant i- virus soft ware. I nt rusion- det ect ion t ools oft en have fewer t han 500 signat ures; virus soft ware can det ect m ore t han 20,000. Virus soft ware com es wit h im plem ent at ions for firewalls, server syst em s, or t he deskt op. These t ools can ident ify, cont ain, eradicat e, and recover wit h m inim al user int ervent ion. Ant i- virus com panies have fully solved t he issue of updat ing a user's signat ure t able wit h a variet y of painless opt ions. Many large organizat ions have sit e licenses wit h t hese soft ware com panies and are pret t y sat isfied. Ant i- virus com panies are already orient ed t o very fast t urnaround of a signat ure t able when a new exploit is det ect ed. These soft ware com panies oft en have com panion product s wit h securit y capabilit ies.

The m at ch is so perfect t hat I cannot underst and why we aren't seeing t hese product s dom inat e t he indust ry. I t would be so easy t o m ake t he changes t o t he NAI or Sym ant ec personal firewalls t o let t hem serve as net work int rusion det ect ion syst em s, but wit h every soft ware release, t hey seem t o m ove furt her and furt her away from providing a t ool t hat is indust rial st rengt h. Next , we will discuss int rusion det ect ion in hardware. Cisco, m ore t han any ot her com pany, has been int ent ionally pursuing put t ing int rusion det ect ion in t he net work it self, so t hat you have hardware- based int rusion det ect ion solut ions. H a r dw a r e - Ba se d I D There are t hree serious challenges t o net work- based int rusion det ect ion: z

Encrypt ed packet s t hat foil st ring m at ching

z

Fast net works beyond t he speed of t he sensor

z

Swit ched net works

We discuss int rusion det ect ion in t he swit ch short ly. Encrypt ion is an int erest ing problem . I t is good if your organizat ion is doing it and having t he key escrowed. Encrypt ion is a bad t hing if som eone is using it t o evade your det ect ion syst em . How do you know if a bit st ream is encrypt ed? You t est for random ness, of course. This is easy t o do, but expensive in t erm s of CPU cycles. There is an argum ent t hat t his should be done in hardware. I am not sure t his is valid; general- purpose com put ers keep get t ing fast er and fast er. Wit h t hat said, t here are places where applying hardware t o t he problem m akes a lot of sense. One of t he best applicat ions is fast er net s. The perfect place for Cisco SecureI DS is on a card placed in a Cisco rout er or swit ch. This, however, is j ust a t oast er wit hout a power supply. The really int erest ing advances com e by doing lim it ed int rusion det ect ion as a soft ware process in t he rout er or swit ch. This is a desperat ely needed fut ure t rend. One advant age of t his is t hat you finally achieve real- t im e, or wire speed. I n all ot her solut ions ( except int rusion det ect ion in t he firewall) , you det ect t he int rusion right aft er t he packet has flown by. I n t his case, you can lit erally st op it or divert it t o a honeypot . The capabilit y t o do t his seem s t o be at hand wit h t he Policy Feat ure Card t hat is available for t he Cat alyst 6000 swit ches. I am not sure why t hey built t he card, perhaps t o provide a product t o com pet e wit h TopLayer, t he applicat ion layer swit ch t hat well- funded int rusion det ect ion analyst s t urn t o when t hey have t he need for speed. Perhaps t hey proj ect advances in t he QoS m arket t hat I j ust do not see on t he horizon. However, t he abilit y t o filt er, m ark a packet , applicat ion swit ch, or failover swit ch inside t he net work fabric at t he rat e of 5 m illion packet s per second at layer 3— m uch m ore at layer 2—opens a num ber of possibilit ies for det ect ion and prot ect ion. This would include m any of t he aut o- response capabilit ies such as dropping a connect ion, rat e lim it ing, copying t raffic t o a m ore powerful I DS or binary logger, or swit ching t he connect ion t o a honeypot . Like large- scale int rusion det ect ion syst em s, it will be a while before we really know what t o do wit h t ools like t his, but learning should be a lot of fun. Pr ogr a m - Ba se d I D I j ust cannot get over t he size of program s t oday. I used t o own a com put er called a Com m odore 64. The 64 st ood for t he am ount of RAM, 64K. The im plicat ion is t hat t he program s had t o load and run in t hat m em ory space. There is an im port ant lesson t o be learned by com paring t he funct ionalit y of t he Com m odore 64 t o m y 400Mhz Pent ium I I wit h 1024MB of RAM. The applicat ions t hat ran on t he Com m odore had about t he sam e funct ionalit y as m y Microsoft Office suit e. However, t hese program s are huge! I f we are going t o t olerat e bloat ware, and it is clear we will, we m ight as well st art asking for som e securit y in t he program s. At t he sem inal conference for int rusion det ect ion SANS' I D'99, I was fort unat e enough t o break away for an hour t o have lunch wit h Sim son Garfinkle, who is writ ing soft ware designed for special- securit y applicat ions. A lot of securit y soft ware, especially vulnerabilit y- t est ing program s, can be used for m alicious

purposes. He want s t o prot ect his int ellect ual propert y from int rusion ( soft ware piracy) , and he also want s t o ensure t he soft ware cannot be m isused wit hout it being clear and obvious which copy of t he soft ware is t he origin. Can soft ware prevent or det ect t hat it is being copied or m isused? For a while, t his was a big issue for com put er gam es, at least t he copy- prot ect ion aspect . I t doesn't seem t o be such a hot t opic t oday. None of t he gam es m y son has bought require a dongle. One of t he forensics t ools I use, Expert Wit ness, has som e degree of license prot ect ion built in wit h a hardware dongle. Microsoft m ust have som e schem e wit h it s st range orange st icker on t he CDs, t he long pin num bers, and it s t echniques for phoning hom e and inspect ing t he net work for license violat ions. Sim son, however, was t aking t he issue a lot m ore seriously t han any of t hese com panies appear t o be. He was proposing a series of count erm easures, including encrypt ing segm ent s of t he program s and chaining checksum s. Let 's t ake t his a st ep furt her. Could a crit ical program det ect t hat it is under at t ack? Suppose sendm ail or Bind had a st at ic library of securit y funct ions. The program could t hen det ect an unaut horized ent it y is t rying t o access it , or t hat t he input it is receiving is act ually binary code. I t could t hen block t he at t ack and raise an alarm . Program s could even develop profiles about t heir uses so t hat t hey can det ect t hat som eone " out of profile" is accessing t heir files and t ake som e preprogram m ed act ion. St ill anot her way t o do int rusion det ect ion at t he program level is t o put a wrapper around t he program , which is m ost cert ainly an em erging t rend. The first wrapper was Wiet se Venem a's TCP Wrapper program , which was a wonderful securit y t ool for years—alt hough perhaps xinet d wit h I CMP support is m ore appropriat e t oday. But , t he concept has been ext ended. You m ight want t o check out im m unix ( www.im m unix.org) . I would expect t hat , for I nt ernet facing applicat ions, t his will be an em erging t hem e t o t he point t hat event ually, sound pract ice will be t o chroot it , wrap it , or bot h. Sm a r t Au dit or s This em erging t rend was in t he book t he first go around and it didn't happen. I put it in again in t he second edit ion and t here was som e progress—not enough for m e t o get hired by Miss Cleo—but I am st icking wit h t his as an em erging t rend! According t o Alan Kay, t he best way t o predict t he fut ure is t o invent it , and by t he t im e t his book is in your hands, SANS should be engaged in helping t o est ablish pragm at ic t ools and resources for audit ors. Audit ors are already sm art —t hat is why t hey do t he audit ing and you do t he sweat ing. Audit ors are st art ing t o underst and securit y t echnology and pract ices at a rapid rat e. The days are gone and will not ret urn when t hey ask whet her you have a firewall, nod when you say " yes," and t hen walk away. I t hink t he em erging t rend is for audit ors t o underst and securit y- assessm ent t ools and t o be able t o operat e t hem . Audit ors can visit your sit e, plug in, and, while

t hey are int erviewing you, run an assessm ent t ool. They can t hen com pare your answers against t he assessm ent —cheerful t hought , eh? Alt hough it will be a pain for syst em adm inist rat ors when we are audit ed, knowledgeable, equipped audit ors could be one of t he m ost effect ive count erm easures against t he increasing t hreat . Hackers, t rust ed insiders, and m alicious code aut hors are not really t hat sm art ; we are j ust a bit lazy, careless, and naive. So when we m ake a m ist ake or get sloppy, it leaves a hole t hat at t ackers find and exploit . I f we are held account able, we act ually do t he t hings t hat we know we ought t o do and t he organizat ion benefit s.

Su m m a r y All dat a t hat I have indicat es t hat t he fut ure looks good for t he int rusion- det ect ion analyst . We will have plent y of work t o do, and we should be able t o get decent pay for our work. Good analyst s are in ext rem e dem and, and t hat should not change in t he near t erm . Com panies are st art ing t o underst and t hat t he skills com ponent is im port ant and are asking for GCI A cert ificat ions, or dem onst rat ed abilit y for higher paying j obs. Tools, t echniques, and t raining are being developed t o count er t he t hreat s, and som e of t hese will m ake our lives easier. Thank you for reading t his book. I have enj oyed t eam ing wit h Judy and Mart y on t his updat e, and I t hank t hem for t heir skills and insight s. Truly t his is becom ing an analyst 's handbook. Please grant m e one closing not e, one m ore m inut e of your precious t im e. The ht t p: / / www.incident s.org/ resource depends upon t he involvem ent of t he com m unit y and m ay well have t o close at som e point . While it is t here, your book com es wit h a warrant y, a way t o st ay up- t o- dat e, a forum t o discuss anyt hing you don't underst and or disagree wit h, and m ost im port ant , a place for you t o share your insight s. Please get involved. We welcom e every nat ion, every point of view, and det ect s from every brand of int rusion- det ect ion soft ware. I nt rusion det ect ion is in it s infancy and needs t o im prove. That can only happen if you get involved. See you on I ncident s!

Pa r t V: Appe n dix e s A Exploit s and Scans t o Apply Exploit s B Denial of Service C Det ect ion of I nt elligence Gat hering

Appe n dix A. Ex ploit s a n d Sca n s t o Apply Ex ploit s

I n t his appendix, we will exam ine a num ber of net work t races. Each has a st ory t o t ell. Most of t hese t races are in t he TCPdum p form at . This form at is consist ent wit h t he t races in t he book TCP/ I P I llust rat ed, Volum e 1: The Prot ocols, by Richard St evens ( published by Addison Wesley, 1994) . This reference should be at t he fingert ips of any serious int rusion- det ect ion analyst

Fa lse Posit ive s This appendix st art s wit h som e of t he errors analyst s are prone t o m ake. Alt hough t he Com put er I ncident Response Team s ( CI RTs) hire som e t op- not ch analyst s, t he errors in t his first sect ion are j ust subt le enough t hat t hey m ight slip by t hem as well. On t he surface, m any CI RTs say t hat t hey prefer t hat you report liberally, even if you are afraid it m ight be a false posit ive. I agree, t o a point , alt hough I t hink t hat if you are not sure what som et hing is you should say so right in t he report ! I n t he final analysis, you ( as t he analyst ) are closest t o t he dat a. You see t he net work t raffic on a daily basis. To st eal a line from Am erica's second- favorit e bear, " Only you can prevent false posit ives." All Re spon se , N o St im u lu s The following t race is t he classic pat t ern com m only m ist aken for a backdoor. Before going t oo far, however, t ake a look at som e of t he charact erist ics of t he t race so t hat you don't m iss anyt hing. At 7: 17, t he sensor observed a packet from m ysyst em , t he source port was echo ( or 7) , t he packet was addressed t o t arget 1 dest inat ion port 24925, and t he size was 64 byt es:

TIME 07:17:09.615279

SRCHOST SRCPORT > DSTHOST DSTPORT mysystem.echo > target1.24925:

Proto Size udp 64

The first t im e I saw t his, m y blood pressure went t hrough t he ceiling; I j ust knew I was dealing wit h a backdoor. Why, you m ight ask? Well I knew t hat m y sit e blocked incom ing echo at t he firewall, so it was not possible t hat som eone was bouncing echoes off of m ysyst em . Therefore, m y reasoning was t hat I was eit her dealing wit h som e form of m alicious code, a UDP flooder of som e sort t hat had a signat ure of source port 7, or t here was a backdoor. Now, t hat was bad reasoning because no one in his right m ind would writ e m alicious code t hat used 7 as a source port —it would be t oo likely t o draw at t ent ion. When I searched for t he st im ulus t raffic, however, I could not find it , and t hat is what confused m e. I n t rut h, t he net work perim et er had changed over t he weekend and som eone really was bouncing echoes off of m ysyst em . Why didn't I see t he st im ulus t raffic? The t wo m ost likely possibilit ies are asym m et ric rout ing and a m isconfigured spanning port . Som e older im plem ent at ions of swit ched net works in spanning m ode only span one direct ion of t he t raffic, which can cause a false posit ive. Here is t he t race:

07:17:09.615279 07:17:10.978236 07:17:11.001745 07:17:11.146935 07:17:12.254277 07:17:12.350014 07:17:12.835873 07:17:13.266794 07:17:13.862476 07:17:14.032603 07:17:14.579404 07:17:14.619173 07:17:14.792983 07:17:14.879559 07:17:15.308270

mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo mysystem.echo

> > > > > > > > > > > > > > >

target1.24925: udp 64 irc.some.where.40809: udp 600 irc.some.where.14643: udp 600 irc.some.where.49911: udp 600 irc.some.where.28480: udp 600 irc.some.where.20683: udp 600 target1.5134: udp 64 irc.some.where.16911: udp 600 target1.32542: udp 64 irc.some.where.32193: udp 600 irc.some.where.24455: udp 600 irc.some.where.5120: udp 600 irc.some.where.47466: udp 600 target1.16878: udp 64 irc.some.where.12234: udp 600

Spa n n in g Por t s Swit ched net works are a m aj or challenge for net work- based int rusion det ect ion. A sensor wit h a single net work int erface, one t hat list ens in prom iscuous m ode and also report s t o t he analysis st at ion, m ight upset som e swit ched net work configurat ions. I f your net work operat ions folks want you t o add a second int erface t o t he sensor, you should t ry t o accom m odat e t hem . Use one int erface t o list en in prom iscuous m ode; it doesn't even need an I P address. The ot her int erface can be for com m unicat ion wit h t he sensor. I n fact , t his is pret t y m uch t he best pract ice for running a net work int rusion- det ect ion sensor t hese days as it helps prot ect t he sensor from at t ackers and m akes it harder t o det ect .

I f t he preceding t race is not caused by a m isconfigurat ion of a spanning port on a swit ched net work, what else could cause it ? A backdoor connect ion or m alicious code could cert ainly cause t his pat t ern, but m ake t hat your second guess. This t race is t it led " All Response, No St im ulus." I P com m unicat ions generally have a st im ulus and a response. When analyst s encount er t races t hey don't underst and, t heir j ob is t o det erm ine what t he st im ulus was. This det erm inat ion helps answer t he quest ions about what is going on. This t race st ands out because you can t ear t hrough all t he t raffic, but you cannot find t he st im ulus; t his is all t he sensor sees. The event of int erest in t his case is t he packet s being sent t o m ysyst em 's echo port . What else can you learn from t his t race? For st art ers, what is t his echo t hing, and what does it do? The echo program reads a st ring and repeat s it . Think of it as an aut om at ed liberal art s undergraduat e st udent . Now t hat you know t he expect ed behavior of echo, it is possible t o fill in t he blanks for what t he t raffic should have looked like ( if t he sensor is m isconfigured, for exam ple, or if we are dealing wit h a backdoor connect ion) . The sim ulat ed, reconst ruct ed t raffic is as follows:

07:17:09.527910 07:17:09.615279 07:17:10.823651 07:17:10.978236

target1.24925 > mysystem.echo: udp 64 mysystem.echo > target1.24925: udp 64 irc.some.where.40809 > mysystem.echo: udp 600 mysystem.echo > irc.some.where.40809: udp 600

So what does t hat show? I t shows t arget 1 and irc.som e.where sending a st ring t o m ysyst em and get t ing t he st ring echoed back. Now why would t hey do t hat ? The answer is t hey probably wouldn't . Even if one syst em was t o use echo for t est ing or t o t roubleshoot , t wo using it sim ult aneously st ret ches coincidence past t he breaking point . This is probably a denial- of- service wit h t arget 1 and irc.som e.where as t he int ended vict im s. A wise rule of t hum b is t o t urn off any net work service on a com put er syst em you don't act ually need. I f t he syst em adm inist rat or for m ysyst em had com m ent ed echo out of / et c/ inet d.conf, t his t race would have never happened. I f t his hasn't convinced you t o t urn echo off yet , t hat 's okay—addit ional t races lat er on show m ore fun wit h echo. This t race has yet anot her problem . The dest inat ion port s include 24925, 40809, 14643, 49911, and so on. Because t hese are echo replies, we assum e t hey were t he source port s from t he sending syst em . The range is m ore random t han norm al for source port s, however; generally, you can expect t o see 24925 followed by 24926 and so fort h. Therefore, t hese are probably replies t o craft ed packet s. Mist aking a t race for a " backdoor" pat t ern ( when it is, in fact , a m isconfigured swit ched net work) can happen, but it is not t hat com m on.

Take a look at one final exam ple of " All Response, No St im ulus" before m oving on. At first glance, t his t oo m ight be perceived t o be an at t ack of som e sort :

11:38:54.010000 11:39:43.180000 11:53:37.780000 11:56:43.690000 12:15:52.550000 12:25:41.800000 12:45:07.470000 12:45:31.530000 12:58:23.350000

masker.com masker.com masker.com masker.com masker.com masker.com masker.com masker.com masker.com

> > > > > > > > >

192.168.133.127: icmp: address mask is 0xfffffe00 172.16.33.116: icmp: address mask is 0xfffffe00 192.168.58.105: icmp: address mask is 0xfffffe00 172.16.178.85: icmp: address mask is 0xfffffe00 172.16.121.67: icmp: address mask is 0xfffffe00 172.16.247.72: icmp: address mask is 0xfffffe00 172.16.110.69: icmp: address mask is 0xfffffe00 172.16.167.73: icmp: address mask is 0xfffffe00 192.168.214.116: icmp: address mask is 0xfffffe00

Rem em ber t he I CMP address m ask request ? I t asked a host t o respond wit h t he subnet m ask of t he net work on which it resided. Alt hough t he TCPdum p out put does not have t he word reply in it , you do see t he words address m ask and a hexadecim al num ber. These are replies t o address m ask request s. All t he host s receiving t hese replies are nonexist ent host s, however, so t hey could not have init iat ed t he request . Again, it appears t hat t he culprit is spoofing t he 192.168 and 172.16 I Ps and firing t hem at m asker.com . Why would som eone m ost likely do t his? An educat ed guess is som e kind of flooding at t em pt t o m asker.com using a different delivery m echanism t han an I CMP echo request . Trut hfully, it really doesn't m at t er what kind of act ivit y you direct at a t arget host if flooding and perhaps a denial of service are t he int ent . Now, t ake a look at a false posit ive t hat has fooled m any beginning analyst s. Sca n or Re spon se ? Take a look at t he following det ect t hat appeared on Shadow's hourly web wrapup. Shadow is configured t o look for t raffic dest ined for UDP port 1080, which is t he socks proxy server. There are som e associat ed exploit s, so we want t o be alert ed when som eone shows int erest in t he socks port . Here it is:

18:20:12.080000 dns.com.53 > myhost.com.1080: 5 NXDomain* 0/1/0 (128) 18:20:12.300000 dns.com.53 > myhost.com.1080: 6 NXDomain* 0/1/0 (119) 18:20:12.410000 dns.com.53 > myhost.com.1080: 7* 1/0/0 (48)

But , look carefully at what is going on in t his out put . Does anyt hing look vaguely fam iliar t o you? Concent rat e on t he not at ion aft er t he 1080. I s t hat your final answer, or perhaps m aybe you want t o use a lifeline t o t he audience? What about t he source port ? A correct response does not yield a m illion dollars or help rat ings during TV Sweeps m ont h, but isn't t his rem iniscent of som e kind of DNS act ivit y? Yes, it appears t o be a response from dns.com t o m yhost .com for m ult iple DNS queries t hat were issued. The ident ificat ion num bers for t he queries are 5, 6, and

7, and query num ber 7 received one resource record, no aut horit y records, and no addit ional records. Because t his sm acks m ore of response t han scan, you need t o look at out bound t raffic from your net work t o see whet her t his was a DNS query init iat ed by m yhost .com . Sure enough, t he following out put put s t his all in perspect ive:

18:20:11.870000 myhost.com.1080 > dns.com.53: 5+ (50) 18:20:12.090000 myhost.com.1080 > dns.com.53: 6+ (41) 18:20:12.310000 myhost.com.1080 > dns.com.53: 7+ (32)

The explanat ion is t hat m yhost .com request ed resolut ion of queries 5, 6, and 7 from dns.com . The client select ed ephem eral source port 1080 on which t o issue t hese queries. When t he responses cam e back from m yhost .com , t hey were direct ed t o dest inat ion port 1080. Shadow cannot correlat e what we j ust did, however, and so blindly fires any t im e a scan is det ect ed on it s signat ure filt ers. The bot t om line is t hat t his is a false posit ive. One of t he m ost com m on false posit ives, however, is t he SYN flood. SYN Floods As an analyst , one of t he scary calls for m e t o m ake is a SYN flood. I t is very easy for an int rusion- det ect ion syst em t o be wrong about t his when, in fact , t his det ect act ually is a false posit ive. I f t he SYN flood com es from a known host ile address, or if ot her host ile act ivit y is associat ed wit h t he connect ion, or if it is very obvious ( 50 or m ore connect ion at t em pt s in less t han a m inut e, for exam ple) , I m ight report t he act ivit y. Ot herwise, I t end t o sit on it and wat ch for furt her act ivit y. Va lid SYN Flood

The following t race shows an act ual SYN flood:

14:18:22.5660 14:18:22.7447 14:18:22.8311 14:18:22.8868 14:18:22.9434 14:18:23.0025 14:18:23.1035 14:18:23.1621 14:18:23.2284 14:18:23.2825 14:18:23.3457 14:18:23.4083 14:18:23.9030 14:18:24.0052

flooder.601 flooder.602 flooder.603 flooder.604 flooder.605 flooder.606 flooder.607 flooder.608 flooder.609 flooder.610 flooder.611 flooder.612 flooder.613 flooder.614

> > > > > > > > > > > > > >

server.login: server.login: server.login: server.login: server.login: server.login: server.login: server.login: server.login: server.login: server.login: server.login: server.login: server.login:

S S S S S S S S S S S S S S

1382726961:1382726961(0) 1382726962:1382726962(0) 1382726963:1382726963(0) 1382726964:1382726964(0) 1382726965:1382726965(0) 1382726966:1382726966(0) 1382726967:1382726967(0) 1382726968:1382726968(0) 1382726969:1382726969(0) 1382726970:1382726970(0) 1382726971:1382726971(0) 1382726972:1382726972(0) 1382726973:1382726973(0) 1382726974:1382726974(0)

win win win win win win win win win win win win win win

4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096

Did t hat look fam iliar? Maybe t his will help: Source: t sut om [email protected] ( Tsut om u Shim om ura) , com p.securit y.m isc Dat e: 25 Jan 1995 " About six m inut es lat er, we see a flurry of TCP SYNs ( init ial connect ion request s) from 130.92.6.97 t o port 513 ( login) on server. The purpose of t hese SYNs is t o fill t he connect ion queue for port 513 on server wit h 'half- open' connect ions so it will not respond t o any new connect ion request s. I n part icular, it will not generat e TCP RSTs in response t o unexpect ed SYN- ACKs." Fa lse Posit iv e SYN Flood

Aft er you com pare t he preceding excerpt from t he Mit nick at t ack wit h t he following t race, you m ight wonder what t he heck t he difference is. Well, t he differences are quit e subt le. The source port increm ent s in bot h t races, as does t he sequence num ber. The TCP window size is t he sam e: 4096 byt es. Clearly, t here are t wo TCP ret ries wit h four packet s each shown below, not e t he st at ic source port and st at ic sequence num ber and t he 3, 6, 12 t im e int erval. The arrival t im es of t he packet s are very sim ilar. So how do we sort t his out ?

14:02:22.5166 14:02:25.5669 14:02:31.7447 14:02:42.8311 14:02:58.8868 14:03:01.9434 14:03:07.0025 14:03:19.1035

host.2104 > server.25: S 1382726960:1382726960(0) win 4096 host.2104 > server.25: S 1382726960:1382726960(0) win 4096 host.2104 > server.25: S 1382726960:1382726960(0) win 4096 host.2104 > server.25: S 1382726960:1382726960(0) win 4096 host2.3311 > server.25: S 2382927964:2382927964(0) win 4096 host2.3311 > server.25: S 2382927964:2382927964(0) win 4096 host2.3311 > server.25: S 2382927964:2382927964(0) win 4096 host2.3311 > server.25: S 2382927964:2382927964(0) win 4096

What a difference a sm all change, em ail rat her t han a different service, m akes! Em ail is expensive, at least t o m ail relays. I f t he em ail relay cannot push t he m ail out t he first t im e, t he relay m ust t ry again an hour lat er. I f you not ice t he t im e, you get a hint of what is t o com e. The " vict im " of t he denial–of- service at t ack here is not a vict im at all, it is a m ail server and it is down. The m ail is queued up all over t he world t rying t o send it t he m ail. Every hour t hese syst em s, all over t he world, t ry again, oft en near t he t op of t he hour. So, we have t his false SYN flood condit ion. Anot her very com m on false posit ive is Microsoft I nt ernet Explorer visit ing a web page. I t creat es a connect ion for each GI F, JPEG, HTML, and so fort h, up t o a lim it of 32. As a rule of t hum b, t herefore, do not report a SYN flood on TCP 25, TCP 80, or TCP 443. Even bet t er, as a general rule, be very slow t o believe your I DS or t o report a SYN flood ( especially because you are j ust beginning your j ourney as an analyst ) . Most

com m ercial int rusion- det ect ion syst em s produce false posit ives on SYN floods so oft en t hat you have t o set t heir count ers t o a very high num ber, which m eans t hey will never det ect a real SYN flood. The good news is t hat m ore m odern operat ing syst em s can resist SYN floods of low num bers of SYNs, so it is becom ing safer and safer t o ignore t hem . The SYN floods t hat do affect m odern syst em s are very high volum e and difficult not t o det ect . Alt hough SYN floods in low volum es m ight be safe t o ignore, t he Windows Troj an horses ( such as Back Orifice) cert ainly are not . These program s can give an at t acker t ot al cont rol over an infect ed com put er. When dealing wit h a high- risk problem such as Back Orifice, t he analyst should not t urn t hat filt er off on t he int rusion- det ect ion syst em even if t he filt er generat es false posit ives. Ba ck Or ifice ? Troj an horses and scanning for Troj ans account s for a large num ber of t he at t acks bet ween m id- 1997 and t he present . Back Orifice and Net bus were t he original front runners in lat e 1998 or early 1999, and t hen SubSeven becam e a m aj or force in lat e '99 and early 2000. The default port for Back Orifice is 31337 UDP, and 12345 TCP for Net bus ( port 12346 as well, alt hough I have never seen t his in act ual use) . Most Troj ans can be configured t o operat e at ot her port s of course, which can m ake it harder t o locat e t hem . Furt her, 31337, like 666 and t he hex pat t erns dead beef are oft en of hacker act ivit y. We saw t his following t race t wice in a single day; I j ust had t o chuckle:

11:20:44.148361 ns1.com.31337 > ns2.arpa.net.53: 38787 A? arb.arpa.net. (34) 11:52:49.779731 ns1.com.31337 > ns1.arpa.net.53: 39230 ANY? hq.arpa.net. (36)

This is a great t im e t o m ent ion t hat TCPdum p has a desire t o be helpful. Alt hough t his is a UDP t race, it does not say UDP like t he first echo exam ple of t his chapt er. I nst ead, TCPdum p uses t his opport unit y t o t ell us m ore about t he packet because it knows DNS ( UDP port 53) , because DNS has it s own form at . Our client syst em ns1.com is doing a nam e lookup on t he DNS server ns* .arpa.net . So what are t he 31337s doing t here? As an analyst , t his was t he quest ion I want ed t o answer when I saw t he t race. We pulled t he packet , print ed it in hex, ran it t hrough t cpshow, and com pared it t o ot her DNS lookups. I t was norm al. Before BI ND 8, t he expect ed, alt hough not required, behavior from a nam e server doing a UDP lookup is t hat t he source port is 53 as well. Som et im es, I have seen t he source port as 137, indicat ing t hat t he client is a Windows syst em . Why 31337? Like all of us, I was busy at work, so I forgot about it unt il an analyst at anot her

sit e flagged t he sam e pat t ern t o m y at t ent ion. I picked up t he phone and st art ed working m y way t hrough t his corporat ion unt il I finally found t he bright young chap who m anaged t he DNS server. I t old him what I saw: Nort hcut t : I am seeing source port 31337s com ing t o various DNS servers. Young Chap: Uh, we've looked int o it , and it is not Back Orifice. Nort hcut t : I know t hat , but it set s off every int rusion- det ect ion syst em t hat sees it . Young Chap: You should fix your int rusion- det ect ion syst em . Nort hcut t : No. You fix your source port or m y sit e will block you, and m y friend's sit es will block you; your com pany will lose it s cont ract s, and you will lose your j ob. He asked who I was again, and we st art ed t o m ake progress t oward a solut ion. So, we had a false posit ive in a sense; it was not an at t ack. I nst ead, it was j ust a young kid who figured t hat because he could configure a DNS syst em , he was " eleet ." He j ust needed a bit of calibrat ing and everyt hing was all right . I gnoring t he t raffic leads t o som e dangerous choices; an analyst should not disable an int rusion- det ect ion syst em filt er, for exam ple, for a pot ent ially dangerous at t ack signat ure. The analyst m ust verify t hat t he det ect is not a false posit ive before report ing it . Som e people t hink I was overly harsh wit h t he young chap. I would ask t hem t o keep in m ind t he problem s such act ivit y could cause at t he CI RT level. Rem em ber, only you can prevent false posit ives. Not e t hat m odern DNS servers running BI ND 8 choose an unprivileged port above 1024, but t hey probably won't choose 31337 consist ent ly. This st ory also illust rat es how im port ant it is for your organizat ion not j ust t o report det ect s t o your CI RT, but also t o share wit h ot her int rusion- det ect ioncapable organizat ions t hat have som et hing in com m on wit h you. This is how I det erm ined t he 31337 wasn't j ust a fluke. Also, at t im es you m ight need t o shun an I nt ernet address block if t hey are being ant isocial.

Sh u n n in g W or k s! Once, a m aj or I nt ernet service provider was not providing support when it s address block was being used t o at t ack our sit es. Tim e and t im e again we t ried t o reach it s organizat ion t o get help. Finally, we blocked t hem ( em ail, web, t he whole nine yards) . Wit hin t hree weeks, t hey were scream ing in pain because t hey were st art ing t o lose m oney; corporat e

cust om ers were pulling out . They agreed t o be responsive in t he fut ure and t o t riple t heir I nt ernet abuse st aff. Who could ask for m ore? This concludes t he discussion about com m on false posit ives. St rict ly speaking, t he exploit is when t he at t acker goes for t he kill and t he soft ware or t echnique exploit s a vulnerabilit y in a com put er syst em . I n act ual pract ice, it is very difficult t o dist inguish bet ween scanning for vulnerabilit ies and t he act ual at t ack. I n fact , t he current generat ion of at t ack t ools do bot h; t hey scan t o find vulnerabilit ies and t hey also at t ack. Therefore, t his sect ion cont ains a bit of m ix and m at ch, prim arily considering vulnerabilit ies, but also t ouching on scanning for vulnerabilit ies when appropriat e. I am not t he only one st ruggling wit h cat egorizing t hese t races in a nice organized m anner. The research side of int rusion det ect ion has been working on t his problem for years and has not yet produced an accept ed t axonom y of at t acks. The Dat abase of Vulnerabilit ies, Exploit s, and Signat ures ( DOVES) proj ect released a CD- ROM wit h it s work on cat egorizat ion in February 1999. For furt her inform at ion, cont act Dr. Mat t Bishop ( m ailt o: [email protected]) . Mit re has fost ered t he creat ion of t he Com m on Vulnerabilit y Enum erat ion ( CVE) . The CVE is probably t he m ost significant effort and enj oys wide support from t he vendor com m unit y; m ore t han 2,000 vulnerabilit ies have been accept ed by it s edit orial board at t his t im e wit h an addit ional 1,700 candidat es. For furt her inform at ion, check out CVE's web sit e at cve.m it re.org. The following sect ion exam ines t races from I MAP exploit at t em pt s.

I M AP Ex ploit s No series of exploit s has reaped as m uch havoc on t he I nt ernet as I MAP. Buffer overflows, such as t he I MAP vulnerabilit y, are not uncom m on; several m aj or problem s have occurred wit h DNS buffer overflows as well. Because t hese program s run as root , t he at t ack is pot ent ially devast at ing, leaving t he at t acker wit h root access. 1 0 1 4 3 Sign a t u r e Sou r ce Por t I M AP The pat t ern here is t he classic pat t ern of one of t he m ost devast at ing buffer overflows ever unleashed on t he I nt ernet . Not e t hat t his scan cont ains t wo dest inat ion net works. Also not e t he t im e gap bet ween packet s. The gap is so large because t his scan was t arget ing every Class B net work on t he I nt ernet . This t race com es from m id- 1997, and t his part icular signat ure is rarely seen now:

14:13:54.847401 newbie.hacker.org.10143 > 192.168.1.1.143: S 14:24:58.151128 newbie.hacker.org.10143 > 172.31.1.1.143: S 14:35:40.311513 newbie.hacker.org.10143 > 192.168.1.2.143: S

14:43:55.459380 14:54:58.693768 15:05:41.039905 15:13:59.948065

newbie.hacker.org.10143 newbie.hacker.org.10143 newbie.hacker.org.10143 newbie.hacker.org.10143

> > > >

192.168.2.1.143: S 172.31.2.1.143: S 192.168.2.2.143: S 192.168.3.1.143: S

1 1 1 Sign a t u r e I M AP The following t race is anot her I MAP scan/ exploit t hat has a repeat able signat ure. The fixed source port , t he fixed sequence and acknowledgm ent fields wit h t he 111, and of course t he window size of 0 is a nice t ouch. From a signat ure- use st andpoint , t his one is part icularly int erest ing. We st art ed t o see it in lat e 1998 following t he large num bers of source port 0 and SF set scans, ( t hese are shown next ) , and t hen it disappeared. I n early 1999, t his signat ure reappeared. I have no idea what t he st ory behind t his behavior is; it is as if t he soft ware got lost for a few m ont hs! Here is t he t race:

00:25:09.57 00:25:09.59 00:42:50.79 00:43:24.05 00:43:24.07 00:44:20.42 00:44:42.62 00:44:42.64 00:44:42.67 00:44:42.69

prober.2666 prober.2666 prober.2666 prober.2666 prober.2666 prober.2666 prober.2666 prober.2666 prober.2666 prober.2666

> > > > > > > > > >

relay.143: S 111:111(0) win 0 relay.143: S 111:111(0) win 0 web.143: S 111:111(0) win 0 relay.143: S 111:111(0) win 0 relay.143: S 111:111(0) win 0 relay2.143: S 111:111(0) win 0 ns2.143: S 111:111(0) win 0 ns2.143: S 111:111(0) win 0 ns1.143: S 111:111(0) win 0 ns1.143: S 111:111(0) win 0

Ex ploit Por t s w it h SYN / FI N Se t One of t he fascinat ing pat t erns t o wat ch has been t he various m ut at ions of a pat t ern called SYN/ FI N ( or m ore com m only, SF) . This is one of t he m ost significant pat t erns in int rusion det ect ion in t he sense t hat an analyst will alm ost cert ainly have seen t his and should be expect ed t o know t his pat t ern. The earliest inst ant iat ion I am aware of is t he at t ack Jackal.c from lat e 1996, and t he m ost recent variat ion I have seen was a buffer overflow against secure shell in Decem ber 2001. At t ackers set SYN/ FI N because it passes t hrough a st at ic packet filt er, because t hey block on a SYN only. However, if a packet wit h SYN/ FI N get s t o eit her a Windows or UNI X syst em wit h t hat port open, t hey respond wit h a SYN/ ACK. This is great from an at t acker's point of view, because it penet rat es t he perim et er and st ill let s t hem com prom ise t he syst em . Take your t im e wit h t his sect ion t o look at som e of t he m aj or variat ions of t his pat t ern and t o learn it s hist ory. Sou r ce Por t 0 , SYN a n d FI N Se t The first clue I had about t he following t race was a post t o bugt raq in March 1998. I did not act ually pick t his t race up for anot her m ont h. Here, t he signat ure is source port 0, which is not logical; and bot h SYN and FI N flags are set , which is

also not logical. An int rusion- det ect ion syst em ought t o be able t o pick up t his kind of t race! Not e t he random - appearing subnet s 26, 24, 17, 16, 24, as well as host s. This is possibly t o m ake t he scan less obvious. Also not e t he speed of t he scan. Scan det ect ors should be able t o det ect five connect at t em pt s t o five different host s in about a quart er of a second. Take a look:

13:10:33.281198 newbie.hacker.org.0 374079488:374079488(0) win 512 13:10:33.334983 newbie.hacker.org.0 374079488:374079488(0) win 512 13:10:33.357565 newbie.hacker.org.0 374079488:374079488(0) win 512 13:10:33.378115 newbie.hacker.org.0 374079488:374079488(0) win 512 13:10:33.474966 newbie.hacker.org.0 374079488:374079488(0) win 512

> 192.168.26.203.143: SF > 192.168.24.209.143: SF > 192.168.17.197.143: SF > 192.168.16.181.143: SF > 192.168.24.194.143: SF

The preceding scan present s several int erest ing advant ages. FI Ns m ight be allowed t hrough filt ering devices even if SYNs are not . This im proves t he probabilit y of a response. Also, because t he FI N signals connect ion t ear down, som e logging syst em s will pot ent ially fail t o report t he connect at t em pt . SYN/ FI N was a t radem ark of a scanning t ool nam ed j ackal, which was purport ed t o penet rat e firewalls. The challenge wit h t his signat ure is t hat m ore t han one exploit / scan is believed responsible for creat ing it . A m ore current t ool t hat can generat e a sim ilar signat ure is nm ap, t he m ost effect ive int elligence- gat hering t ool yet deployed by at t ackers. Sou r ce Por t 6 5 5 3 5 a n d SYN FI N Se t The following t race is an int erest ing variant of t he preceding t race. This was collect ed in Novem ber 1998. There is speculat ion t hat t his pat t ern is probably t he result of an at t ack t ool t hat enables t he user t o select any source port she want s. Alt hough I have no doubt t hat such a t ool eit her exist s or will exist in t he near fut ure, t hat does not begin t o explain why int rusion- det ect ion analyst s have collect ed hundreds of exam ples wit h source port 0 and a large num ber wit h source port 65535. I n t he early days, before 1999, analyst s had not yet collect ed any exam ples wit h any ot her source port and SYN/ FI N set . The source port was hardcoded int o t he soft ware and t hat t he source port 65535 is a second- generat ion code branch from t he original. The t race follows:

16:11:38.13 IMAPPER.65535 > ns2.org.143: SF 3794665472:3794665472(0) win 512 16:11:38.13 IMAPPER.65535 > ns2.org.143: SF 3794665472:3794665472(0) win 512

D N S Zon e Follow e d by 0 , SYN FI N Ta r ge t in g N FS

Alt hough I MAP has been an effect ive t arget of opport unit y for at t ackers, it cert ainly isn't t he only t arget . The following t race has sim ilarit ies t o t he source port 0 and SYN/ FI N set pat t ern. I n t his case, however, we are dealing wit h a double dipper. First , t he at t acker t ries an at t ack against TCP 53, which is also DNS. The difference is you use TCP 53 rat her t han UDP 53 when you want a zone t ransfer—in essence, a host t able of t he sit e. As previously not ed, t he 0 source port and t he SF flag set s are a signat ure for a com m on I MAP exploit . This at t ack direct ed at NFS alm ost cert ainly shares code wit h t hat exploit . These code branches help t o ident ify at t ackers who writ e, m odify, or com pile code as opposed t o t hose who can run only exist ing exploit s. What apparent ly has happened is t hat t he at t acker has bolt ed a different exploit ont o an older delivery syst em . Say what ? Well, we m ake t he case lat er t hat at least som e part of what we are dealing wit h is warfare. I n weapons, one oft en separat es t he warhead from t he delivery syst em . For inst ance: z

z

z

Archers could use one t ip for firing int o infant ry and a different arrowhead for launching flam ing arrows at cast les. Cat apult s could t hrow rocks t o bust walls or dissuade charges, but could also t hrow flam ing m issiles if t hat was what was needed. Modern cruise m issiles can carry convent ional weapons and slip in t he enem y's bedroom window ( or so t he Gulf War foot age would have us believe) or t hey can carry nuclear warheads.

I n each of t hese cases, a delivery syst em can fire m ult iple exploit s ( I m ean warheads) . You should not be surprised t o see t he sam e principle in inform at ion warfare. The arrowhead in t he following t race is t he NFS port , 2049. The signat ure of t he delivery m echanism ( source port 0 and SYN/ FI N set ) is shown in bold:

12:11:48 prober.21945 > ns1.net.53: SF 1666526414:1666526414(0) win 512 12:11:49 prober.21951 > ns2.net.53: SF 11997410:211997410(0) win 512 12:36:54 prober.0 > relay.net.2049: SF 3256287232:3256287232(0) win 512 12:37:03 prober.0 > web.net.2049: SF 3256287232:3256287232(0) win 512 12:37:05 prober.0 > relay2.net.2049: SF 3256287232:3256287232(0) win 512

This pat t ern has cont inued. One classic sight ing was in February 2000; post ers t o GI AC were report ing source port 0, SF set t o TCP port 109, t he POP2 service. This pat t ern has m ost recent ly m ut at ed t o reflexive source and dest inat ion port s—for exam ple, source port 109, SF set t o dest inat ion port 109. A final not e about t he preceding t race: This individual is probably a rookie. I f you hit a sit e wit h an exploit and do not get in, it is far wiser t o m ove t o a different I P address before

t rying again. Using t he sam e I P address t wice increases your risk of a knock on t he door from federal agent s. That said, t his was t he first t im e we saw t he code branch t o t he NFS exploit . There are no easy answers. And, it is st ill going on. I n Decem ber 2001, we picked up an at t ack against secure shell ( TCP 22) , source port 22, dest inat ion port 22, SF set .

Sca n s t o Apply Ex ploit s This final sect ion discusses a num ber of int erest ing pat t erns t hat , wit h t he except ion of discard and I P- 191, t end t o use well- known vulnerable port s. One challenge you face when sort ing out t he exploit t ools from t he scan t ools is t hat because m ost sit es use t heir firewall or filt ering rout er t o block risky port s, it becom es difficult t o collect inform at ion. Wit h TCP- based at t acks, for inst ance, t he t hree- way handshake never com plet es because t he connect ion is blocked, which m akes it all but im possible t o know t he int ent ion of t he at t acker. The first t race exam ined here is t he m scan pat t ern, a favorit e t ool of at t ackers. m sca n The following t race is repr esent at ive of one of a very com m on at t ack pat t ern, m scan. The m ult iscan exploit code is widely available and does not indicat e an " eleet " or well- connect ed at t acker. That said, it get s it s fair share of syst em com prom ises, because it scans for vulnerabilit ies present in a large num ber of syst em s connect ed t o t he I nt ernet :

06:13:23.188197 06:13:28.071161 06:13:33.107599 06:13:38.068035 06:13:43.271220 06:13:47.831695

bad.guy.org.6479 bad.guy.org.15799 bad.guy.org.25467 bad.guy.org.3861 bad.guy.org.14296 bad.guy.org.943

> > > > > >

target.mynetwork.com.23: target.mynetwork.com.80: target.mynetwork.com.143: target.mynetwork.com.53: target.mynetwork.com.110: target.mynetwork.com.111:

S S S S S S

AL- 98.01 AusCERT Alert m ult iscan ( m scan) Tool 20 July 1998, ft p: / / ft p.auscert .org.au/ pub/ auscert / advisory/ AL- 98.01.m scan: " AusCERT has received report s indicat ing a recent and subst ant ial increase in net work scanning act ivit y. I t is believed t hat int ruders are using a new t ool called 'Mult iscan' or 'm scan'. This t ool enables t he user t o scan whole dom ains and com plet e ranges of I P addresses t o discover well- known vulnerabilit ies in t he following services: st at d nfs cgi- bin Program s ( 'handler', 'phf' & 'cgi- t est ,' for exam ple) X, POP3, I MAP, Dom ain Nam e Servers, finger." So, you ask, " What is a scanner doing in t he exploit chapt er?" Sue m e! The

exploit s for t elnet , Web, I MAP, DNS, POP3, and Port m ap are so num erous and so well known I t hought it was appropriat e. Son of m sca n Of course, if one at t acker has m scan, anot her has t o do it one bet t er. The following t race was first seen in Novem ber 1998. We can learn som e t hings from t his t race. The scan rat e is on t he order of 10 packet s per second. That is no record, but it is fast . We would cert ainly hope our int rusion- det ect ion syst em 's port scan det ect code would t ake not e of 10 SYN packet s t o different port s on t he sam e syst em in one second! What are all t hose port s? Throughout t he book, I use t he I nt ernet Assigned Num bers Aut horit y ( I ANA) paper on port s ( ft p: / / ft p.isi.edu/ innot es/ iana/ assignm ent s/ port - num bers) for services 1024 and below. Above 1024 is a m ess, and we work t hrough t hese port s carefully. I f you have an I nt ernet connect ion, you m ight want t o download a copy of t he port list ing now. Anot her excellent source of inform at ion is an / et c/ services file from a UNI X com put er, t he best being t he one t hat ships wit h FreeBSD. However, I am learning m ore and m ore t o use Google ( www.google.com ) .You sim ply t ype port 12345 or what ever and t hen read t he discussions. Everyone knows 12345 is Net bus, but I didn't know t hat it is also a license m anager. Nor did I know t hat Trend Micro uses t his as a list ening port . I would have never known about t his if I had not queried Google. I f you don't have access t o one, or t he t im e t o go get one, refer t o t he service nam es at t he beginning of each line for t his t race:

Echo- 20:50:19.872769 prober.1454 > mail.relay.7: S 7460483:7460483(0) win 8192 (DF) Discard- 20:50:19.881293 prober.1455 > mail.relay.9: S 7460502:7460502(0) win 8192 (DF) Quote of the Day- 20:50:19.916488 prober.1456 > mail.relay.17: S 7460545:7460545(0) win 8192 (DF) Daytime- 20:50:19.983115 prober.1457 > mail.relay.13: S 7460592:7460592(0) win 8192 (DF) Chargen- 20:50:20.026572 prober.1458 > mail.relay.19: S 7460646:7460646(0) win 8192 (DF) FTP- 20:50:20.118159 prober.1459 > mail.relay.21: S 7460745:7460745(0) win 8192 (DF) Telnet- 20:50:20.215007 prober.1460 > mail.relay.23: S 7460845:7460845(0) win 8192 (DF) Time- 20:50:20.415433 prober.1462 > mail.relay.37: S 7461008:7461008(0) win 8192 (DF) DNS- 20:50:20.475574 prober.1463 > mail.relay.53: S 7461095:7461095(0) win 8192 (DF) Gopher- 20:50:20.616177 prober.1464 > mail.relay.70: S 7461209:7461209(0) win 8192 (DF) Finger- 20:50:20.675549 prober.1465 > mail.relay.79: S 7461295:7461295(0) win 8192 (DF) HTTP- 20:50:20.766639 prober.1466 > mail.relay.80: S 7461396:7461396(0) win 8192 (DF)

TSMUX- 20:50:20.869773 prober.1467 > mail.relay.106: S 7461494:7461494(0) win 8192 (DF) POP2- 20:50:20.983764 prober.1468 > mail.relay.109: S 7461608:7461608(0) win 8192 (DF) POP3-20:50:21.040400 prober.1469 > mail.relay.110: S 7461645:7461645(0) win 8192 (DF) Portmap- 20:50:21.125914 prober.1470 > mail.relay.111: S 7461746:7461746(0) win 8192 (DF) NNTP- 20:50:21.224194 prober.1471 > mail.relay.119: S 7461846:7461846(0) win 8192 (DF) NetBIOS- 20:50:21.325783 prober.1472 > mail.relay.139: S 7461955:7461955(0) win 8192 (DF) SMUX- 20:50:21.415527 prober.1473 > mail.relay.199: S 7462046:7462046(0) win 8192 (DF) REXEC- 20:50:21.483920 prober.1474 > mail.relay.512: S 7462096:7462096(0) win 8192 (DF) RLOGIN- 20:50:21.543247 prober.1475 > mail.relay.513: S 7462194:7462194(0) win 8192 (DF) RSHELL- 20:50:21.577268 prober.1476 > mail.relay.514: S 7462199:7462199(0) win 8192 (DF) PRINTER- 20:50:21.581449 prober.1477 > mail.relay.515: S 7462203:7462203(0) win 8192 (DF) UUCP- 20:50:21.615331 prober.1478 > mail.relay.540: S 7462205:7462205(0) win 8192 (DF)

What is t he (DF) at t he end of each line in t he t race? That is t he spiffy Don't Fragm ent flag. The packet s in t his t race are supposed t o arrive in one parcel or be t hrown away. Having exam ined t he preceding t race, what operat ing syst em is being t arget ed? Most likely, UNI X is t he t arget , because m any of t hese services do not norm ally run on ot her operat ing syst em s. Of course, if t he only answer back from t he scan were port 139, t he at t acker would guess he had det ect ed a Windows box. Could t he 139 port be t arget ed at UNI X, even t hough 139 is norm ally associat ed wit h Windows syst em s? Yes, SAMBA allows UNI X syst em s t o " speak" Net BI OS, and t here are SAMBA exploit s as well. Broad- brush scans such as t hese are one reason I recom m end t he following: z

z

Turn off any service you are not act ively using and wrap services you need wit h TCP Wrappers configured t o deny all and only allow t hose wit h whom you want t o com m unicat e. Firewalls should be configured t o block everyt hing not needed t o conduct an organizat ion's business.

One last t hing before m oving on—did you not ice t he packet t hat was out of sequence? Not ice how as t im e increases various fields, such as source port s and dest inat ion port s, also increase. Now on t he fourt h line down, one of t he dest inat ion port s is out of sequence. No big deal; on t he I nt ernet , packet s can arrive out of order. Now, check it s source port . I nt erest ing! This could pot ent ially be a signat ure t hat enables us t o ident ify t his pat t ern.

Acce ss Bu ilde r ? Look at one m ore m ult iscan. This is t ypical of several t hat appeared in t he Decem ber 1998/ January 1999 t im e fram e. Not e t hat t he scan t arget s Back Orifice ( act ually, it t arget s 31337; t o t arget Back Orifice, t his should be UDP) and Net bus. One of t he int erest ing t hings about t his scan is t hat it hit s t he sam e m achine on t he sam e port t wice. Also, not e t he at t em pt t o access port 888. This port has an official m eaning: I t is 3Com 's Access Builder and is also used for a dat abase:

13:05:02.437871 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:02.442739 scanner.2578 > 192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF) 13:05:03.071918 scanner.2578 > 192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF) 13:05:03.079767 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:03.680841 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:04.274991 scanner.2578 > 192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF) 13:05:04.278967 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:05.391873 scanner.2575 > 192.168.1.1.12345: S 922734:922734(0) win 8192 (DF) 13:05:05.392074 scanner.2576 > 192.168.1.1.31337: S 922734:922734(0) win 8192 (DF) 13:05:06.079211 scanner.2575 > 192.168.1.1.12345: S 922734:922734(0) win 8192 (DF)

Sin gle Ex ploit , Por t m a p The following t race is fairly sim ple. I n t his case, a syst em is t arget ing m ult iple sit es looking for port m apper. An int erest ing t hing about t his scan is t hat t he at t acking host com es from a U.S. Governm ent lab. Despit e t he way t he governm ent is port rayed by t he X- Files and in various m ovies, t his probably is not a covert plot . I nst ead, when you get at t acked by governm ent com put ers, it is an opport unit y t o m ake a difference: That syst em is probably com prom ised. When I called t hat lab, t he fellow in charge of securit y was so t hankful for t he t ip t hat he was willing t o send m e t he at t ack code and dat a files from t he at t acker. The at t ack code was t arget ing rpc.st at d. The dat a files had t wo nam es: XXX.dom ains and XXX.result s, in which XXX was t he t arget of t he at t ack such as m il.dom ains and isp.dom ains. This is called t he shopping list . The result s file was a list ing of syst em s t hat had syst em s wit h act ive, unprot ect ed port m appers. These result s files were presum ably t he shopping list s for t he next st age of t his at t ack, t he act ual exploit . The sensors in t his case were TAMU net loggers, an int erest ing but obsolet e net work- logging soft ware package and t heir t race is shown below.

12/03/97 02:35:53 EB419A7E muon.phy.nnn.gov sunrpc 12/03/97 02:35:56 EB419A7E muon.phy.nnn.gov sunrpc 12/03/97 02:36:02 EB419A7E muon.phy.nnn.gov sunrpc 12/03/97 02:36:08 F94110F6 muon.phy.nnn.gov sunrpc 12/03/97 02:47:46 C4AF4C22 muon.phy.nnn.gov sunrpc 12/03/97 02:47:52 C4AF4C22 muon.phy.nnn.gov sunrpc 12/03/97 03:09:26 A63222B3 muon.phy.nnn.gov gw1.havregrace.arpa.net sunrpc 12/03/97 03:09:29 A63222B3 muon.phy.nnn.gov gw1.havregrace.arpa.net sunrpc 12/03/97 03:09:35 A63222B3 muon.phy.nnn.gov gw1.havregrace.arpa.net sunrpc

994 -> relay.nnnn.arpa.net 994 -> relay.nnnn.arpa.net 994 -> relay.nnnn.arpa.net 995 -> ns1.nnnn.arpa.net 954 -> 192.168.16.7 954 -> 192.168.16.7 861 -> 861 -> 861 ->

Port 111 TCP is an at t em pt t o access port m apper. This t race was part icularly int erest ing because for several years access at t em pt s on TCP 111 were fairly rare, alt hough UDP 111 at t em pt s were quit e com m on. This part icular at t em pt was a harbinger of t hings t o com e. Not e t hat t he source port s are all below 1024, which indicat es t he process running on t he governm ent syst em is running as root . This syst em is com prom ised! By March 1998, t his exploit was m owing down a large num ber of Sun Solaris system s, m any of which were t he DNS, web, or m ail servers for t heir sit es. This is part icularly int erest ing because t he vulnerabilit y was widely known and t he fix was widely available, as shown here: z

z

z

Com put er Em ergency Response Team ( CERT) put out a warning in Decem ber 1997 at ht t p: / / www.cert .org/ advisories/ CA- 97.26.st at d.ht m . More and m ore UNI X operat ing syst em s were shipping wit h " secure" port m appers. Wiet se Venem a's code t o prot ect port m apper was available at ht t p: / / coast .cs.purdue.edu/ pub/ t ools/ unix/ port m ap.

rexec The following t race is j ust a variet y of rexec at t em pt s. The int erest ing t hing about rexec is t hat it does expect a password for aut hent icat ion. So, why don't t he at t ackers use rlogin inst ead? They are probably t rying default passwords, because rexec does not t end t o log. Also, SGI syst em s shipped for a long t im e wit h a guest account wit h a password of guest . An at t acker could t hen use t his at least t o get reconnaissance inform at ion and probably t o also begin privilege escalat ion. An at t acker has a low chance of being det ect ed unless t he sit e has eit her net work- or host - based int rusion det ect ion.

The following t race represent s how m any at t em pt s?

21:30:17.210000 61440 21:30:22.720000 61440 21:30:46.720000 61440 21:31:02.170000 61440 21:31:07.720000 61440 21:31:31.720000 61440

prober.1439 > 172.20.18.173.512: S 334208000:334208000(0) win prober.1439 > 172.20.18.173.512: S 334208000:334208000(0) win prober.1439 > 172.20.18.173.512: S 334208000:334208000(0) win prober.1449 > 172.20.18.173.512: S 340608000:340608000(0) win prober.1449 > 172.20.18.173.512: S 340608000:340608000(0) win prober.1449 > 172.20.18.173.512: S 340608000:340608000(0) win

Two at t em pt s. Observe t he source port s 1439 and 1449—each is ret ried t wo t im es. Also, not e t he sequence num bers: 33420… for t he first t hree packet s and 34060… for t he second set of t hree packet s. You need m ore dat a t o m ake an educat ed assessm ent , but not ice t hat t he t wo sequence num bers end in 08000. Given t wo dist inct TCP sequence num bers, it is very unlikely t hat t hey would have t his pat t ern. This m ight indicat e som e kind of craft ing of t he sequence num ber. Look at ot her TCP sequence num bers referenced in t he book, and you will discover t hat m ost are fairly unique and do not show such pat t erns. POP3 Here, we have a fast scan wit h nicely uniform arrival t im es. I f t his doesn't set off our scan det ect code, not hing will! A num ber of POP buffer exploit s exist , so t he t arget is easy t o underst and. What is odd about t his t race is t he host select ion. The scan is t arget ing a part icular subnet , num ber 14. But what is t he deal wit h t he host s? I f you were t he analyst on dut y and you saw t his, what would you check for?

20:35:25.260798 20:35:25.279802 20:35:25.281073 20:35:25.287761 20:35:25.290293 20:35:25.295865 20:35:25.303651 20:35:25.317924 20:35:25.319275

bad.guy.org.4086 bad.guy.org.4129 bad.guy.org.4141 bad.guy.org.4166 bad.guy.org.4209 bad.guy.org.4234 bad.guy.org.4277 bad.guy.org.4302 bad.guy.org.4378

> > > > > > > > >

192.168.14.101.110: 192.168.14.119.110: 192.168.14.126.110: 192.168.14.128.110: 192.168.14.136.110: 192.168.14.141.110: 192.168.14.146.110: 192.168.14.173.110: 192.168.14.171.110:

S S S S S S S S S

( I f m y answer differs from yours, it 's okay.) I would want t o know whet her t hese were act ually act ive host s on t he 14 subnet . I f t hey are, t he at t acker already clearly has som e inform at ion about us from a previous int elligence- gat hering effort . I f t hey are act ive host s, and also run popd, it is past t im e t o consider

increasing t he count erm easures for t hat subnet ! Ta r ge t in g SGI Syst e m s? The following t race shows a port scan, but it is pret t y specific and it looks like a UNI X syst em is t he t arget . This is believed t o be t arget ed at SGI UNI X syst em s due t o port 5232, part of t heir dist ribut ed graphics. Unless t he int rusion- det ect ion syst em is weight ing t he I MAP and t elnet port ( and m ost do) , t his scan could easily be m issed because it is only t hree packet s:

21:17:12 prober.1351 > 172.20.4.6.imap: S 19051280:19051180(0) win 512 21:17:12 prober.1352 > 172.20.4.6.5232: S 12879079:12879079(0) win 512 21:17:12 prober.1353 > 172.20.4.6.telnet: S 42734399:42734399(0) win 512

D isca r d When Discard get s a packet , it t hrows it away. When we det ect ed t his, we j oked t hat it m ust be a st udent of Richard St evens ( because he uses Discard for m any of t he exam ples in his book) . I n t his case, four SYNs were at t em pt ed t o each host in t he scan before m oving on t o t he next host in t he scan:

08:02:35 dscrd.net.268 > 192.168.160.122.9: S 1797573506:1797573506(0) win 16384 (DF) 08:02:38 dscrd.net.268 > 192.168.160.122.9: S 1797573506:1797573506(0) win 16384 (DF)

Th r e e - Por t Sca n I added t his scan prim arily because t he added lat ency of t he HTTP port ion of t he scan. I t is m uch slower t han t he rest of t he t race. And as an added bonus, I bet you haven't seen a dayt im e scan before! Most likely, t his is a benign net work m apping effort out of Bell labs called Net sizer—of course, if t he source address happens t o be your prim ary com pet it or, you m ight want t o look int o t his furt her! Here it is:

20:50:04.532822 prober.54934 > myhost.domain: S 2118852885:2118852885(0) win 8760 (DF) 20:50:08.028023 prober.54934 > myhost.domain: S 2118852885:2118852885(0) win 8760 (DF) 20:50:14.432349 prober.54934 > myhost.domain: S 2118852885:2118852885(0) win 8760 (DF)

20:50:27.226116 8760 (DF) 20:50:52.824148 8760 (DF) 20:53:26.414741 8760 (DF) 20:53:29.913485 8760 (DF) 20:53:49.111043 8760 (DF) 20:54:14.710959 8760 (DF) 20:55:05.905554 8760 (DF) 21:00:10.209063 8760 (DF) 21:00:13.703247 8760 (DF) 21:00:20.103798 8760 (DF) 21:00:32.902480 8760(DF) 21:00:58.500635 8760(DF)

prober.54934 > myhost.domain: S 2118852885:2118852885(0) win prober.54934 > myhost.domain: S 2118852885:2118852885(0) win prober.54944 > myhost.http: S 2144702009:2144702009(0) win prober.54944 > myhost.http: S 2144702009:2144702009(0) win prober.54944 > myhost.http: S 2144702009:2144702009(0) win prober.54944 > myhost.http: S 2144702009:2144702009(0) win prober.54944 > myhost.http: S 2144702009:2144702009(0) win prober.54968 > myhost.daytime: S 2196732969:2196732969(0) win prober.54968 > myhost.daytime: S 2196732969:2196732969(0) win prober.54968 > myhost.daytime: S 2196732969:2196732969(0) win prober.54968 > myhost.daytime: S 2196732969:2196732969(0) win prober.54968 > myhost.daytime: S 2196732969:2196732969(0) win

W e ir d W e b Sca n s This scan earns no speed records, but t hat is int ent ional. I s t he at t acker looking for web servers? We could hypot hesize t hey are and UNI X- based web servers at t hat . Sending t he packet t o t he 0 host address is an old- st yle BSD broadcast ; Windows syst em s will fail t o answer. The scan proceeds at a slower rat e so t hat all t he input s can be processed. Not e t he source port rem ains t he sam e for each subnet :

18:45:06.820 61440 18:45:09.356 61440 18:45:12.626 61440 18:45:14.375 61440 18:45:15.184 61440 18:45:16.790 win 61440 18:45:17.970 61440 18:45:20.190 61440 18:45:20.442 61440 18:45:22.695 win 61440

b.t.t.6879 > 172.20.1.0.http: S 1025092638:1025092638(0) win b.t.t.7136 > 172.20.2.0.http: S 1041868014:1041868014(0) win b.t.t.6879 > 172.20.1.0.http: S 1025092638:1025092638(0) win b.t.t.7395 > 172.20.3.0.http: S 1059077568:1059077568(0) win b.t.t.7136 > 172.20.2.0.http: S 1041868014:1041868014(0) win b.t.t.7650 > 255.255.255.255.http: S 1075727476:1075727476(0) b.t.t.7905 > 172.20.5.0.http: S 1092175088:1092175088(0) win b.t.t.7395 > 172.20.3.0.http: S 1059077568:1059077568(0) win b.t.t.8160 > 172.20.6.0.http: S 1108940634:1108940634(0) win b.t.t.7650 > 255.255.255.255.http: S 1075727476:1075727476(0)

18:45:23.648 b.t.t.7905 > 172.20.5.0.http: S 1092175088:1092175088(0) win 61440

TCP Br oa dca st ? Well, t he 0 host I D looks like old- st yle broadcast s, and sm ells like oldst yle broadcast s, but here is a com m ent from one of t he book's reviewers: " First , t here is no such t hing as broadcast ing using TCP. See TCP/ I P I llust rat ed, Volum e I , p. 169: 'Broadcast ing and m ult icast ing only apply t o UDP, where it m akes sense for an applicat ion t o send a single m essage t o m ult iple recipient s. TCP is a connect ion- orient ed prot ocol t hat im plies a connect ion bet ween t wo host s ( specified by I P addresses) and one process on each host ( specified by port num bers) .' " I n fact , t o be sure I t ried t his out against our t est net work, which cont ains about 25 host s—all different OSs and hardware, old soft ware and new soft ware—against several different TCP port s, using bot h t he .0 and t he .255 broadcast s…and no host s will answer t his request . The .0 or .255 address is int erpret ed as a unicast address and no ot her host s on t he net will pick up t he packet . This furt her m akes sense when we t hink about how TCP ident ifies connect ions according t o t he t uple ( src ip, dst ip, src port , dst port ) . I n t he case of a broadcast address, t here is no way t o include t hat address in t he t uple. The at t acker cannot obt ain a broadcast - t ype response from t hese SYN packet s because t here is no way t o negot iat e a t hree- way handshake using a broadcast address." However, rout ers do not work at t he TCP layer, t hey work at t he I P layer; so t his packet is not act ually looking for web servers, it is doing reconnaissance hoping for I CMP error m essages such as unreachables. The following excerpt is anot her web- based scan, from t he access_log of a UNI X com put er running t he Apache web server code. This capt ured t he cont ent s of t he t raffic dest ined for t he ht t pd port . By using bot h t he net work I DS and t he host based logs, we can fuse what is happening. Apache is t he m ost popular web server soft ware in use on t he I nt ernet . This t race is t he result of a popular web server m ult i- CGI - BI N exploit ; whisker or t he nessus t ools are fam ous exam ples. These are com m only in use. We cannot seem t o go a day wit hout som eone t rying t o run one of t hese against www.sans.org:

prober - - [11/Dec/1998:15:28:26 -0500] "GET /cgi-bin/phf/ HTTP/1.0" 404 165 prober - - [11/Dec/1998:15:28:26 -0500] "GET /cgi-bin/php.cgi/ HTTP/1.0" 404 169 prober - - [11/Dec/1998:15:28:26 -0500] "GET /cgi-bin/campas/ HTTP/1.0" 404 168

prober - - [11/Dec/1998:15:28:26 404 172 prober - - [11/Dec/1998:15:28:27 170 prober - - [11/Dec/1998:15:28:27 404 173 prober - - [11/Dec/1998:15:28:27 404 173 prober - - [11/Dec/1998:15:28:27 169 prober - - [11/Dec/1998:15:28:28 404 173 prober - - [11/Dec/1998:15:28:28 HTTP/1.0" 404 175 prober - - [11/Dec/1998:15:29:50 prober - - [11/Dec/1998:15:29:51 169 prober - - [11/Dec/1998:15:29:51 168 prober - - [11/Dec/1998:15:29:51 404 172 prober - - [11/Dec/1998:15:29:52 170 prober - - [11/Dec/1998:15:29:52 404 173 prober - - [11/Dec/1998:15:29:52 404 173 prober - - [11/Dec/1998:15:29:52 169 prober - - [11/Dec/1998:15:29:53 404 173 prober - - [11/Dec/1998:15:29:53 HTTP/1.0" 404 175

-0500] "GET /cgi-bin/htmlscript/ HTTP/1.0" -0500] "GET /cgi-bin/aglimpse/ HTTP/1.0" 404 -0500] "GET /cgi-bin/websendmail/ HTTP/1.0" -0500] "GET /cgi-bin/view-source/ HTTP/1.0" -0500] "GET /cgi-bin/handler/ HTTP/1.0" 404 -0500] "GET /cgi-bin/webdist.cgi/ HTTP/1.0" -0500] "GET /cgi-bin/pfdispaly.cgi/ -0500] "GET /cgi-bin/phf/ HTTP/1.0" 404 165 -0500] "GET /cgi-bin/php.cgi/ HTTP/1.0" 404 -0500] "GET /cgi-bin/campas/ HTTP/1.0" 404 -0500] "GET /cgi-bin/htmlscript/ HTTP/1.0" -0500] "GET /cgi-bin/aglimpse/ HTTP/1.0" 404 -0500] "GET /cgi-bin/websendmail/ HTTP/1.0" -0500] "GET /cgi-bin/view-source/ HTTP/1.0" -0500] "GET /cgi-bin/handler/ HTTP/1.0" 404 -0500] "GET /cgi-bin/webdist.cgi/ HTTP/1.0" -0500] "GET /cgi-bin/pfdispaly.cgi/

I P- Pr ot o- 1 9 1 To t he very best of m y underst anding, t his cannot be an exploit and probably isn't an im m ediat e prelude t o one. I want ed t o include it , however, because I P prot ocol t ypes t hat are not TCP, UDP, or I CMP are not t hat uncom m on as scans. What is ip- prot o- 191? Durned if I know. An 8- bit prot ocol field in t he I P header was set t o 191:

00:32:28.164183 00:32:28.164663 00:32:30.192825 00:32:33.203521 00:32:36.219821 00:32:36.220302 00:32:38.243973 00:32:41.254622 00:32:44.262961 00:32:47.276258 00:32:50.285609 00:32:50.286098

prober > 192.168.0.255: ip-proto-191 48 192.168.4.5 > prober: icmp:192.168.0.255 unreach prober > 192.168.1.255: ip-proto-191 48 prober > 192.168.2.255: ip-proto-191 48 prober > 192.168.3.255: ip-proto-191 48 192.168.4.5 > prober: icmp:192.168.3.255 unreach prober > 255.255.255.255: ip-proto-191 48 prober > 192.168.5.255: ip-proto-191 48 prober > 192.168.6.255: ip-proto-191 48 prober > 192.168.7.255: ip-proto-191 48 prober > 192.168.8.255: ip-proto-191 48 192.168.4.5 > prober: icmp:192.168.8.255 unreach

What is t he origin of t he ip- prot o- 191 not at ion? TCPdum p t ries t o figure out t he I P prot ocol by looking at t he appropriat e field in t he I P header. TCPdum p knows t he com m on prot ocol t ranslat ions. I f it finds a 1 in t his field, it labels it as I CMP in t he out put —6 is TCP, and 17 is UDP. I f it is not a prot ocol t hat it knows about , however, it uses t he ip- prot o not at ion wit h t he num ber t hat it discovered in t he prot ocol field. The preceding out put also shows a response from 192.168.4.5. This response, in it self, supplies som e reconnaissance about t he net work. Even if you do not get a prot ocol unreachable, you st ill have every chance of seeing a host unreachable.

Su m m a r y Analyst s m ake m any com m on m ist akes. These include SYN floods, m isconfigured net works, and being t oo quick t o m at ch a signat ure. I f possible, t ry t o avoid sending false posit ives t o your CI RT. Som e of t he t ricks at t ackers are using for eit her st ealt h or bet t er penet rat ion, such as set t ing bot h t he SYN and FI N flag, allow t hese packet s t o be t rivially det ect ed.

Appe n dix B. D e n ia l of Se r vice

I n February 2000, denial- of- service at t acks were t he hot t opic. Wit h a net work of m ore t han 2,000 com prom ised syst em s, m ost of t hem via a DNS buffer overflow, at t ackers shut down m aj or high- profile I nt ernet sit es such as CNN and eBay. Alt hough t he end of t his chapt er covers t hese at t acks, t hey are t he except ion and not t he rule for denial of service. I n general, denial- of- service at t acks groan on and on, doing lit t le harm besides wast ing people's t im e and bandwidt h and occasionally crashing a syst em . I n t he vast m aj orit y of t hese at t acks, t he source address is faked or " spoofed." Please be very slow t o phone t he owners of t he address space t hat you t hink j ust hit you wit h a denial of service and read t hem t he riot act ! One day it m ight be your address t hat is spoofed. This is a short chapt er divided int o t wo sect ions. The first sect ion deals wit h denial- of- service brut e- force at t acks t hat are widespread and regularly det ect ed even if t hey are not all t hat well known. The second sect ion includes addit ional well- known at t acks, but t hese are m ore elegant ; in fact , t hey t end t o be one- packet kills—t hat is, a single at t acker packet t hat can freeze or shut down a syst em .

Br u t e - For ce D e n ia l- of- Se r vice Tr a ce s These brut e- force pat t erns have reached a point t hat t hey are known by alm ost all I nt ernet inst it ut ions. The curious t hing is t hat I st ill find sit es and syst em s vulnerable t o t hese at t acks. Keep in m ind t hat one of t he charact erist ics of m any of t he denial- of- service at t acks is t hat t he at t acker can use one of your syst em s t o cause harm t o som eone else. The fixes are well published and well underst ood; please im plem ent t hem . Only you can prevent SYN floods, UDP floods, Sm urf, and Echo- Chargen! Sm u r f The Sm urf at t ack has no effect except t o consum e bandwidt h. The m ost im port ant t hing t o consider wit h regard t o t he effect iveness of Sm urf is t hat for your sit e's

I nt ernet connect ion t o run sm oot hly, you depend on t he securit y policy of ot her people's sit es. This is a very old at t ack, but you st ill see it deployed wit h t he m ost current at t ack t ools. Sm urf is st ill deployed for exact ly one reason: I t st ill works. I n t he following case, spoofed.pound.me.net alm ost cert ainly did not really send t he echo request t o 192.168.1.255. I nst ead, an out side com put er int erj ect s t his int o t he net work, as shown in Figure B.1. The poor spoofed addressee will pot ent ially get hit wit h a large num ber of I CMP echo replies. I f spoofed is on a slow I nt ernet connect ion, t his m ight be harm ful; and if a large num ber of host s reply t o t he Sm urf, dam age can be done t o fast net works. Figu r e B.1 . I CM P de n ia l of se r vice .

Cisco published t he following field not ice t it led " Minim izing t he Effect s of 'Sm urfing' Denial of Service At t acks." The following quot at ion is from t hat docum ent : A Scenario: Assum e a co- locat ion swit ched net work wit h 100 host s, and t hat t he at t acker has a T1. The at t acker sends, for exam ple, a 768 kbps st ream of I CMP echo ( ping) packet s, wit h a spoofed source address of t he vict im , t o t he broadcast address of t he " bounce sit e." These ping packet s hit t he bounce sit e's broadcast net work of 100 host s. Each of t hem t akes t he packet and responds t o it , creat ing 100 ping replies out bound. By m ult iplying t he bandwidt h, you see t hat 76.8 Mbps is used out bound from t he " bounce sit e" aft er t he t raffic is m ult iplied. This is t hen sent t o t he vict im ( t he spoofed source of t he originat ing packet s) . 1 1

www.cisco.com / warp/ public/ 707/ 5.ht m l

I chose t o reference a Cisco t echnical m anual because Cisco rout ers—t he m ost widely deployed rout ers in t he world—are one of t he prim ary keys t o elim inat ing Sm urf at t acks. Let 's exam ine how t he at t ack works and t hen t he count erm easures:

00:00:05.327 00:00:05.342 00:00:14.154 00:00:14.171 00:00:19.055 00:00:19.073 00:00:23.873

spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net

> > > > > > >

192.168.15.255: 192.168.1.255: 192.168.15.255: 192.168.1.255: 192.168.15.255: 192.168.1.255: 192.168.15.255:

icmp: icmp: icmp: icmp: icmp: icmp: icmp:

echo echo echo echo echo echo echo

request request request request request request request

All for On e Many denial- of- service at t acks and net work- m apping probes use broadcast s, packet s addressed t o all m em bers of a net work, t o accom plish t heir purposes. RFC 919 set s several st andards for broadcast s, including t he rule t hat 255.255.255.255 m ust not be forwarded by a rout er or rout ing host . How did 255.255.255.255 com e t o be? The local net work layer can always m ap an I P address int o a dat a link layer address. Think about swit ched net works—t hat is exact ly how t hey work. So, t he choice of an I P " broadcast host num ber" is som ewhat arbit rary. Som et hing needed t o be select ed, and it seem ed reasonable t hat it should be one t hat was not likely t o be assigned t o a real host . The num ber whose bit s are all 1s had t his propert y. Keep t he idea of all 1s in m ind; we will look at pat t erns where t he broadcast is not 255.255.255.255 due t o subnet m asking, but t he all 1s rem ains t rue. The address 255.255.255.255 denot es a broadcast on a local hardware net work, which m ust not be forwarded by a rout er or rout ing host . This address m ight be used, for exam ple, by host s t hat do not know t heir net work num ber and are asking som e server for it . A com m on case of t his is a diskless workst at ion; as it is boot ing up, it broadcast s a request for help in finding it s operat ing syst em . I t s server hears t he request and answers, providing t he next st ep in t he boot up process and t hen t he cust om ized files t his syst em needs t o do it s j ob. Therefore, a host on net 36, for exam ple, m ight do t he following: z

z

Broadcast t o all of it s im m ediat e neighbors by using 255.255.255.255 Broadcast t o all of net 36 by using 36.255.255.255

( Not e t hat unless t he net work has been broken up int o subnet s, t hese t wo m et hods have ident ical effect s.) I f t he use of " all 1s" in an oct et of an I P address m eans " broadcast ,"

using " all 0s" could be viewed as m eaning " unspecified." There is probably no reason for such addresses t o appear anywhere but as t he source address of a bootp. bootp is one of t he prot ocols used t o help diskless syst em s and rout ers load t heir operat ing syst em s and configurat ion files. Alt hough t here is a legacy I CMP I nform at ion Request dat agram , t hese are obsolet e and should not occur in norm al t raffic. As a not at ional convent ion, however, we refer t o net works ( as opposed t o host s) by using addresses wit h 0 fields. For exam ple, 36.0.0.0 m eans " net work num ber 36," whereas 36.255.255.255 m eans " all host s on net work num ber 36." 2 2

www.library.ucg.ie/ Connect ed/ RFC/ 919/ 7.ht m

D ir e ct e d Br oa dca st

I f you det ect a pat t ern such as t he following 255.255.255.255, t he odds are t hat it was sent as a sim ple broadcast and has been expanded by your rout er, as shown here: 1 . A packet originally dest ined for 172.20.4.255 assum es a net m ask of 255.255.255.0, t he size of a Class C net work. This broadcast s t o all host s of t he 172.20.4 net work. 2 . A rout er, possibly in your organizat ion, has t he 172.20.4 int erface. When it copies t he packet from t he I nt ernet and rebuilds it on t he 4 int erface, it expands t he broadcast , t hereby referencing all host s served by t hat int erface. Therefore, it rewrit es t o broadcast as 255.255.255.255. I n t he following t race, t he broadcast has been expanded. The all 1s broadcast is as described earlier, and t he legacy all 0s broadcast has been expanded t o t he net work port ion of t he net m ask. Who answers t hese expanded pings? Every syst em t hat hears t hem ! Therefore, one packet com ing in from a spoofed address ends up being am plified t o hundreds or t housands of packet s. Sit es t hat do not block incom ing I CMP are known as Sm urf am plifiers. You can find a list ing of t hese, including t he t op 10, at www.powert ech.no/ sm urf or ht t p: / / www.net scan.org/ . ( I n t his case, it is not a great honor t o be in t he t op 10.) Take a look at t he t race:

05:20:48.261 05:20:48.263 05:21:35.792 05:21:35.819 05:22:16.909 05:22:16.927 05:22:58.046 05:22:58.061

spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net spoofed.pound.me.net

> > > > > > > >

192.168.0.0: 255.255.255.255: 192.168.0.0: 255.255.255.255: 192.168.0.0: 255.255.255.255: 192.168.0.0: 255.255.255.255:

icmp: icmp: icmp: icmp: icmp: icmp: icmp: icmp:

echo echo echo echo echo echo echo echo

request request request request request request request request

I n t erm s of count erm easures, you can build perim et er defenses t hat are denial- ofservice resist ant . I nst ead of connect ing a proxy or applicat ion gat eway firewall direct ly t o your I nt ernet connect ion, you m ight want t o have a rout er first . Aft er all, t hey are m ore efficient at blocking high- bandwidt h at t acks sim ply because t hey are designed t o operat e at " wire speeds." You should also block out going packet s t hat have a source address not from your net work; t his is known as egress filt ering. You can find exam ples of egress filt ering for a large num ber of rout ers and firewalls in t he GCFW pract ical assignm ent s at www.giac.org/ cert .php. Many denial- of- service at t acks use spoofed source addresses. I f you do not let t hem on t he I nt ernet , you are being a good net - neighbor. Needless t o say, if one of your syst em s is sending out spoofed addresses, t hat is a clue t hat t his box m ight have been com prom ised. Ech o- Ch a r ge n Echo- Chargen is anot her exam ple of a classic brut e- force at t ack t hat uses poorly defended sit es and poorly configured syst em s as am plifiers. This at t ack m ost ly looks for UNI X syst em s as am plifiers, so it is not quit e as pot ent as Sm urf, which uses any syst em . You know how t hey depict t he audiences of t ennis m at ches on cart oons? Everybody's head goes back and fort h following t he ball. This pat t ern is j ust like t hat except t hat t he heads would have t o oscillat e at j ust under t he speed of light . Echo is UDP port 7; if it receives a packet it echoes back t he payload. I f you send echo an " a," it replies wit h an " a." Chargen ( charact er generat or) is UDP port 19. I f you send Chargen any charact ers, it replies wit h a pseudo random st ring of charact ers. I n t he following t race, an out sider spoofs a num ber of connect ions t o various host s' Chargen port s. The hope here is t hat t hey will reply back t o t he echo port and a gam e of Echo < - - > Chargen ping- pong will begin burning bandwidt h and CPU cycles. You can st ill det ect m ake it even m ore port s t hrough your be com m ent ed out

08:08:16.155354 08:21:48.891451 08:25:12.968929 08:42:22.605428 08:47:21.450708 08:51:27.491458 08:53:13.530992

t his in act ual use, but it is becom ing m ore rare. You can help rare. There is no reason t o allow packet s addressed t o t hese organizat ion's firewall or filt ering rout er. These services should of your UNI X syst em 's inet d.conf files:

spoofed.pound.me.net.echo spoofed.pound.me.net.echo spoofed.pound.me.net.echo spoofed.pound.me.net.echo spoofed.pound.me.net.echo spoofed.pound.me.net.echo spoofed.pound.me.net.echo

> > > > > > >

172.31.203.17.chargen: 192.168.14.50.chargen: 192.168.102.3.chargen: 192.168.18.28.chargen: 172.31.130.93.chargen: 172.31.153.78.chargen: 172.31.146.49.chargen:

udp udp udp udp udp udp udp

I st udied m art ial art s for m any years and event ually becam e an inst ruct or. Twice a

year we would have a black belt t est . The school's m ast er would invit e ot her m ast ers t o form a panel for t he t est . Of course, it is cust om ary t o bow t o t hese m ast ers, and t hey bow back. I have a m ischievous st reak, and from t im e t o t im e I would bow, t hey would bow, I would bow again, t hey would bow again, and so on, unt il t hey finally looked up wit h a pained expression and walked away. I cannot look at an Echo- Chargen t race wit hout t hinking about t hat lit t le t rick. The exam ple t race is UDP, but I have found you can m ake t he oscillat ion wit h t he TCP variant of t hese services as well, alt hough I haven't figured out how t o spoof t he address and m ake it work. For fun, if you have Cisco rout ers, t elnet t o your rout er's Echo or Chargen port . For inst ance, $ telnet myrouter 7 accesses t he TCP echo port . Many Cisco rout ers seem t o have t hese open by default .

Ele ga n t Kills Brut e- force at t acks t end t o rely on spoofed addresses t o provide a bit of cover for t he at t acker. One packet kills can operat e wit h a m uch lower foot print . They t ake advant age of flaws in t he I P st ack's capabilit y t o deal wit h illegal condit ions, or even bad program m ing. The following sect ions look at several of t hese, including Echo- Chargen, Teardrop, Land, and a fun lit t le at t ack against an advent ure gam e called Doom . Te a r dr op Sm urf and Echo- Chargen work by brut e force; Teardrop works by finesse. I t t akes advant age of a sim ple fact : Net work prot ocol st acks are not good at m at h. They are especially bad at negat ive num bers. This is anot her ancient at t ack, and alt hough it is st ill in use, I do not see it t hat oft en. My int rusion- det ect ion st udent s m ust com plet e a pract ical assignm ent t o achieve cert ificat ion. The assignm ent varies in t he det ails, but essent ially it is t o collect and analyze about 10 net work t races. Quit e oft en, t hey inst rum ent t heir cable m odem s and collect dat a for a while, and Teardrop shows up on m any of t he pract ical assignm ent s. Therefore, it is st ill being t ried. The next quest ion is t his: Does it st ill work? Sure, but only on unpat ched or older operat ing syst em s. The following is an exam ple of a Teardrop t race:

10:25:48.205383 wile-e-coyote.45959 > target.net.3964: udp 28 (frag 242:36@0+) 10:25:48.205383 wile-e-coyote > target.net: (frag 242:4@24)

Because it has been a long t im e since Chapt er 3, " Fragm ent at ion," perhaps a rem inder is in order. The t op line shows a fragm ent nam ed 242 wit h 36 oct et s of dat a for offset 0. The second line shows 4 m ore oct et s of dat a for offset 24. Therefore t o service t his packet , t he operat ing syst em would have t o rewind from 36 t o 24. Negat ive num bers can t ranslat e t o very large posit ive num bers, and so

t he operat ing syst em is likely t o scribble all over som e ot her program 's sect ion of m em ory. Try t his a couple t im es and you kill t he syst em . The core problem is t hat m any I P st acks do not know how t o deal wit h negat ive, or illegal, num bers. I m ost recent ly saw t his when t he PROTOS t oolkit was released along wit h a CERT advisory on February 12, 2002. HD Moore, a securit y researcher, was running t he t oolkit against a Red Hat , Linux 7 box and caused a segm ent at ion fault . We t ried t o look at t his packet wit h Et hereal, but it killed Et hereal. A TCPdum p t race is shown here:

18:49:54.519006 10.0.0.1.59108 > 10.0.0.2.161: .1.3.6.1.2.1.1.5.0[len3 192.168.102.3

02:21:53

0 206.256.199.8

19 -> 164.256.23.100

02:28:20

0 206.256.199.8

19 -> 164.256.140.32

02:30:29

0 206.256.199.8

19 -> 192.168.18.28

02:30:44

0 206.256.199.8

19 -> 164.256.67.121

02:34:47

0 206.256.199.8

19 -> 164.256.140.32

02:35:28

0 206.256.199.8

19 -> 147.168.130.93

02:36:56

0 206.256.199.8

19 -> 192.168.18.28

02:39:23

0 206.256.199.8

19 -> 147.168.153.78

02:41:55

0 206.256.199.8

19 -> 147.168.130.93

Apparent ly, som e individuals are so bored t hat t hey are spoofing a bunch of addresses, such t hat if t hese at t ackers chance on folks playing Doom , t he Chargen out put m ight disrupt t he gam e in som e way ( and a single packet can be enough t o do t he t rick) . The following sim ulat ed reconst ruct ed t race shows t he cause and effect of such an act ion, finding a Doom server. Again, 147.168.153.78 in t his case is spoofed, and t he act ivit y is being caused by an unknown I P address. Alt hough Doom t raffic is

becom ing m ore rare t hese days, a sim ilar gam e called Quake st ill generat es a packet or t wo. Here is t he Doom t race:

12/03/97 02:39:22 19 12/03/97 02:39:23 666

0 147.168.153.78 0 206.256.199.8

666 -> 206.256.199.8 19 -> 147.168.153.78

Act ually, I had not seen t his t race in a long t im e and was going t o rem ove it from t he m at erial; t hen t he following variant showed up again in January 1999. Not e t hat t he int rusion- det ect ion syst em did flag t his. What t ips us off and let s us know t hat ?

17:58:13.725824 17:58:13.746748 18:03:24.133079 18:03:24.157238 21:05:22.503299 21:05:26.152327 23:50:15.728480 23:50:15.751821

doomer.echo > 172.20.196.51.666: udp 1024 (DF) doomer.echo > 172.20.196.51.666: udp 426 (DF) doomer.echo > 172.20.46.79.666: udp 1024 (DF) doomer.echo > 172.20.46.79.666: udp 426 (DF) dns1.arpa.net.domain > doomer.domain: 42815 (44) doomer.domain > dns1.arpa.net.domain: 42815* 2/0/0 (98) (DF) doomer.echo > 172.20.76.2.666: udp 1024 (DF) doomer.echo > 172.20.76.2.666: udp 426 (DF)

Sure! The dom ain lookup is a big hint ! We have already discussed Echo and Chargen, and we have seen t hem show up t oget her. What is going on? The at t acker is bouncing off an open echo port t o cover his t racks, t he receiving com put er will see t he syst em wit h echo port in t he source address field, not t he at t acker. The at t acker spoofs t he address of t he t arget m achine t o a m achine, and t hen bounces t raffic off t hese port s ont o t he gam e. The preceding signat ure is a t ough one; 7 t o 666 is also a classic signat ure of a UDP flood denial- of- service program called Pepsi. However, Pepsi scanners do not usually pause for a refreshing DNS lookup. As t his discussion shows, bot h brut e- force at t acks and elegant denial- of- service at t acks t ake advant age of flawed sit e and syst em prot ect ion. How do t hey know which syst em s t o t ake advant age of? I n som e cases, at t ackers sim ply t ry all t he addresses, hoping t o get lucky. I n ot her cases, t hey perform reconnaissance. One of t he best t ools, bar none, t o do t his is nm ap.

nm ap nm ap is t he m ost versat ile scanner available at any price for Windows and UNI X ( and t he price is free) . This soft ware can creat e a large num ber of t races, and in early 1999 was being called t he m ost pot ent denial- of- service engine available. Som e of t he best inform at ion about t he denial- of- service effect s of nm ap was published by t he National Infrastructure Protection Center (NI PC) . NI PC produces biweekly report s called CyberNot es. Elect r onic copies are available on t he NI PC

web sit e at ht t p: / / www.nipc.gov/ . CyberNot es list s specific vulnerabilit ies t hat nm ap exploit s. I ssue 99- 2, for exam ple, report s a scan on port 427 t hat causes t he dreaded blue screen of deat h on Windows 98 syst em s running t he Novell I nt ranet Client . I cert ainly do not disagree wit h NI PC, but if a piece of net working soft ware dies because it receives a packet on a cert ain port , we should not blam e t he vulnerabilit y scanner. Packet s happen. I n fact , in t he years since nm ap was first released, m any st acks have crashed, but t his has forced t he m anufact urers t o fix t heir product s because nm ap is so prevalent . nm ap is a vulnerabilit y scanner, but it operat es in several powerful m odes, including som e t hat can knock out unpat ched syst em s. These m odes include t he following: z

Vanilla TCP connect ( ) scanning

z

TCP SYN ( half open) scanning

z

TCP FI N, Xm as, or Null ( st ealt h) scanning

z

TCP FTP proxy ( bounce at t ack) scanning

z

SYN/ FI N scanning using I P fragm ent s ( bypasses packet filt ers)

z

UDP raw I CMP port unreachable scanning

z

I CMP scanning ( ping- sweep)

z

TCP Ping scanning

z

Rem ot e OS ident ificat ion by TCP/ I P fingerprint ing

z

Reverse- indent scanning

nm ap was int egrat ed st art ing wit h Shadow 1.6. I t is great . When t he analyst sees a connect ion t o a syst em from t he I nt ernet t hat causes concern, t he analyst can scan t he int ernal syst em . Shadow's default is t o use t he vanilla TCP connect , alt hough all m odes are available. The purpose is t o quickly det erm ine what services t he int ernal syst em has available. And yes, from t im e t o t im e when OS fingerprint ing, I have crashed a syst em or t wo. I guess t he good news is t hat it is really hard for t he at t ackers t o com prom ise t he syst em if you crash it when fingerprint ing it !

M u t a n t Pa ck e t Ar m s Ra ce I n m id- 1998, I was t alking wit h t he developm ent t eam for Cisco's vulnerabilit y scanner, Net Sonar. Mem bers of t he t eam were discussing

t he great pains t hey t ook t o avoid crashing syst em s while scanning t hem . Today, nm ap has som e serious com pet it ion from hping2 when it com es t o generat ing som e seriously funky packet s. I hope t hat an arm s race does not develop bet ween t he t wo of t hem t o see which can do t he m ost harm t he fast est .

D ist r ibu t e d D e n ia l- of- Se r vice At t a ck s Before t he m illennium rollover, I ran int o a form er coworker who, wit hin t he past five years, had ret ired from her com put er- relat ed j ob. Aft er exhaust ing m ore pert inent t opics, I asked her whet her she planned t o fly hom e t o Nebraska for t he Christ m as holiday. I ndeed, she was st aying int o t he New Year. I was curious whet her she had any fears about t he possibilit y of Y2K com put er problem s and flying. She adm it t ed no anxiet y and asked m e whet her t here was anyt hing t hat she should be concerned about . I calm ly m ent ioned a m inor inconvenience of a m assive denial- of- service against all infrast ruct ure syst em s such as power grids, airlines, and banks cont inuing for days, weeks, or even years t o assuage her nonexist ent anxiet y. I nnocent ly enough, she replied, " What 's a denial of service?" Believe m e, t his is a sharp wom an, and I t hought not hing less of her because of her quest ion; I j ust realized t hat m y fears were based on m y exposures, and her peace of m ind was based on her exposures. I believe, however, t hat exposure for m ost of t he rest of t he m edia- connect ed world changed wit h t he denial- of- service at t acks against som e of t he m aj or I nt ernet players, such as Yahoo! and eBay, in February 2000.You could not help but hear on t he night ly news or read on t he front pages of t he newspapers about t hese at t acks t hat felled t hese giant s of e- com m erce. Mont hs lat er, t he m edia st ill buzzes about t he lack of consum er confidence associat ed wit h t hese at t acks m uch as years ago you couldn't read or hear about t he Russian space st at ion Mir wit hout hearing t he word " beleaguered." The soft ware responsible for t hese and m any m ore at t acks is known as dist ribut ed denial of service ( DDoS) because it is a denial of service originat ing from m any different source host s. Thankfully for us as aut hors and perhaps unfort unat ely for you as readers, we haven't capt ured any t raffic associat ed wit h t hese at t acks. But , no discussion of denial of service t oday is respect able unless t he dist ribut ed denial- of- service at t acks are covered. I n t r o t o D D oS Rem em ber t he powerful Sm urf at t ack t hat used an int erm ediat e sit e and all it s responding host s t o am plify a denial- of- service at t ack? That is a drop in t he ocean com pared t o t he m agnit ude of som e of t he dist ribut ed denial- of- service at t acks. I f you look at t he archit ect ure of t he Sm urf at t ack, you will discover t hat t here is really one host ile origin of t he at t ack: A m alicious user at one host craft s one or

m any I CMP echo request s t o a broadcast address of t he am plificat ion sit e wit h a spoofed source I P of t he t arget host . Many am plificat ion host s can m agnify t he int ensit y of t he at t ack. I n a DDOS at t ack, m any different " host ile" host s enlist ed are direct ed t o at t ack a t arget sit e. These so- called host ile host s are com prom ised host s t hat have had dist ribut ed denial- of- service soft ware inst alled on t hem . Maybe t his new public awareness about t hese at t acks will elim inat e som e of t he naive at t it udes of " why would som eone want t o break int o m y com put er…it 's got not hing wort h st ealing." DDoS soft ware com es in m any different incarnat ions, each wit h different t erm inology and t echniques. Am ong all, however, t here is a not ion of a cont rolling com put er t hat direct s t he com prom ised host s t o at t ack a sit e. Therefore, you have m ult iple origins of host ile host s sim ult aneously at t acking t he vict im sit e. The int ent is t o clog t he port als of t he vict im sit e by consum ing t he resources for handling legit im at e t raffic. The vict im sit e has t o figure out a way t o block t he DDoS t raffic while st ill allowing t he legit im at e t raffic. D D oS Soft w a r e Hist orically, four different DDoS program s were known: Trinoo, Tribe Flood Net work ( TFN) , TFN2K, and St acheldraht ( Germ an for barbed wire) . Wit h each new release, t hey seem t o have evolved int o m ore com plex packages wit h richer funct ionalit y. Most work on Linux or Solaris host s, and TFN2K works on Windows NT host s. Report s of new Windows- like DDoS are surfacing. Som e new t erm inology m ust be int roduced. At t he t op of t he DDoS at t ack, you have a host , usually known as t he client , which is used by t he person coordinat ing t he at t ack. Next , at a layer below t hat , you have a host or host s known by t he t erm m ast er or handler. The m ast er cont rols subservient host s t o launch at t acks. Finally, at t he bot t om , you have host s known bot h as agent s or daem ons, which act ually launch t he at t acks. The t erm inology get s t ricky because it som et im es differs for t he individual at t acks. Tr in oo

This soft ware uses cont rolling host s known as m ast ers, and at t acking host s known as daem ons. The com m unicat ions bet ween t he client and t he m ast ers and t he m ast ers and t he daem ons is done using TCP and UDP. There are st andard port s, but t hese can be alt ered. Trinoo can send only UDP floods t o random dest inat ion port num bers on t he vict im host . Com m unicat ions bet w een host s in an unalt ered configurat ion are as follows:

client master

master: daemons:

destination port TCP 27665 destination port UDP 27444

daemons

master:

destination port UDP 31335

TFN

Chapt er 4, " I CMP," discussed TFN. Basically, t here are TFN m ast ers and daem ons, which again represent t he cont rolling host s and t he at t acking host s. The com m unicat ion bet ween m ast er and daem on is done via an I CMP echo reply. The I CMP echo reply can direct t he daem on t o send a UDP flood, TCP SYN flood, I CMP echo flood, or a Sm urf at t ack. The m ast er can m anipulat e t he I P ident ificat ion num ber and payload of t he I CMP echo reply t o ident ify t he t ype of at t ack t o be launched. TFN can also spoof t he source I P t o hide t he origin of t he at t ack. TFN 2 K

TFN2K was t he first of t he DDoS program s t o be t ransport ed t o Windows. The com m unicat ions bet ween t he m ast er and agent s can be encrypt ed and can be over TCP, UDP, or I CMP wit h no ident ifying port s. The m ast er can spoof t he source I P so t hat if it is det ect ed, t he real m ast er cannot be ident ified. The agent can at t ack using a TCP SYN flood, a UDP flood, I CMP flood, or Sm urf ( as we saw wit h TFN) . Addit ionally, t he at t acking agent can alt ernat e am ong t hese t ypes of at t acks for any given at t ack. And, t he agent - generat ed at t ack packet s have a spoofed source I P by default . St a ch e ldr a h t

St acheldraht is a com binat ion of Trinoo and TFN wit h encrypt ion added t o com m unicat ions bet ween t he client and handler and t he handler and t he agent s. Agent s can generat e TCP SYN floods, UDP floods, I CMP floods, and Sm urf at t acks against t he vict im . Default com m unicat ions are as follows:

client handler agent

handler: TCP port 16660 or 60001 agent: TCP port 65000 or ICMP echo reply handler: TCP port 65000 or ICMP echo reply

Today, since t he discovery of t he leaves worm wit h t he f.exe m alicious code in June 2001, t he m ain em phasis seem s t o be on cont rolling syst em s from I RC channels or using flooding I RC bot s. I f you see t raffic ent ering or leaving your net work on TCP 6667 ( act ually TCP 6660–6670) you probably should consider t aking a close look at it , unless you are sure t he owner of t he syst em is act ually using I RC t o chat .

Su m m a r y I n denial- of- service at t acks, t he source address is probably spoofed. Please report t hem t o your CI RT anyway. Many of t he denial- of- service at t acks are very old and well underst ood; t his does not m ean t hey aren't effect ive. Alt hough t here is

not hing im pressive about Echo- Chargen, I was j ust t alking wit h a m aj or I nt ernet service provider t hat lost a T3 circuit for t hree hours t o an oscillat ion. As far as DDoS at t acks, you can do lit t le right now if you becom e a vict im sit e. A docum ent is available from ht t p: / / www.incdent s.org/ t o guide you st ep by st ep if you t hink one of your UNI X host s m ight be infect ed wit h one of t hese Troj ans. A wise analyst will download and read t his from www.incident s.org/ react / t roj an.php before she has t o deal wit h an infect ed syst em . And, you cert ainly can t ake som e m easures for prevent ing your sit e from becom ing a launching ground. First , m ake sure you have egress filt ering t hat allows packet s t o leave your net work only if t hey cont ain source I Ps from your net work. There is an excellent paper on egress filt ering available from I ncident s.org, www.incident s.org/ prot ect / egress.php. This prevent s source I P spoofing used by m any of t he at t acks. Also, you can configure your int rusion- det ect ion syst em t o look for som e of t he signat ures so t hat you have det ect ion capabilit ies if you do becom e a launching sit e. And, as t rit e it sounds, you have less chance of a host com prom ise if you block unnecessary t raffic int o your sit es and your host s are well pat ched and m aint ained. This prevent s t he com prom ises necessary t o inst all t he DDoS soft ware.

Appe n dix C. D e t e ct ion of I n t e llige n ce Ga t h e r in g

Chapt er 16, " Archit ect ural I ssues," raised t he issue t hat CI RTs have t o focus prim arily on com prom ised syst em s. And t hey do! How would you feel if you were on t he phone wit h your CI RT t rying t o get inform at ion you need t o deal wit h t he lat est nast y Troj an horse code and t hey said, " Sorry we are devot ing all our resources t o a new int elligence- gat hering t echnique?" Wise int rusion analyst s devot e a lot of at t ent ion t o t he prevent ion, det ect ion, and report ing of m apping t echniques. They know t hat recon is j ust part of t he gam e. As at t ackers am ass high- qualit y inform at ion about t he layout of net works and dist ribut ion of operat ing syst em s, it enables t hem t o specifically t arget t heir at t acks. You do not want t o allow your organizat ion t o get in a one- exploit , one- kill sit uat ion! The line bet ween exploit / denial of service and recon probe couldn't be t hinner. Any exploit t hat fails ( or succeeds) also provides int elligence about t he t arget . This appendix cont ains m any t races showing inform at ion- gat hering t echniques and reviews som e of t he ways an at t acker m ight m ap t he net work and it s host s. This appendix also briefly covers Net BI OS- specific issues because t here are so m any deployed Windows syst em s. The appendix concludes by exam ining som e of t he socalled st ealt h m apping t echniques.

N e t w or k a n d H ost M a ppin g The goal of host m apping is j ust t o det erm ine what host s or services are available in a facilit y. I n som e sense, t he odds are in t he analyst s' favor; we are, aft er all, defending very sparse m at rices. Suppose you have a Class B net work, 172.20.0.0 ( which is 65,536 possible addresses) . There are also 65,536 TCP port s and 65,536 UDP port s possible per host . That m eans t hat t he at t acker has 23 t rillion+ possible t arget s. Scanning at a rat e of 18 packet s per second, it would t ake a shade under

5 m illion years t o com plet ely scan t he net work. Because com put ers have a life span of bet ween t hree and five years, t he rat e of change confounds t he usefulness of t he scan. Now t o be sure, at t ackers are com ing up wit h sm art er and fast er scanning t echniques. An at t acker has no need t o consider all possible port num bers. Fift y TCP and UDP port s account for t he probable services, so t he t arget space is som et hing in t he range of 163 m illion ( which could be scanned in less t han four m ont hs at 18 packet s per second) . Hm m m m , t hat is achievable! And if t he sit e doesn't have int rusion det ect ion, t he sit e owners will probably never know whet her t he at t acker's scan random izes t he addresses and port s a bit . I f t he at t ackers can get an accurat e host m ap, however, t hey can t urn t he t ables on t hose of us who defend net works big t im e. Many address spaces are light ly populat ed. I f t he at t acker can det erm ine where t he host s are, t hey have a serious advant age. Suppose our Class B net work is populat ed wit h only about 6,000 com put ers, for inst ance, and t he at t acker can find t hem . Now t he at t acker can scan t he populat ed host s on t he net work, at 18 packet s per second, in less t han 10 days—and t here are st ill m uch m ore efficient ways t o do t he scan. I n fact , if we allow I CMP echo request broadcast s, t hey can ping m ap our net work wit h only 255 packet s. The point of t he st ory is obvious. I f at t ackers cannot get int elligence inform at ion about our sit e, t hey are forced t o guess about a very sparse m at rix. I f we do let t heir int elligence- gat hering probes succeed, t hey don't have t o do m uch guessing at all. So how can an at t acker get such an accurat e host m ap? Many sit es st ill m ake a host t able available for FTP download. Ot her sit es allow DNS zone t ransfers. Or, perhaps t he at t acker has t o work t o discover t his inform at ion wit h host scans. Chapt er 4, "I CMP," covered som e of t he m ore rudim ent ary I CMP m apping t echniques. The crudest of t hem all t ried t o send I CMP echo request s t o individual host s and creat ed a lot of noise doing so. We also saw t he broadcast I CMP echo request s t hat at t em pt ed t o m ap a net work by sending t he I CMP echo request s t o t he .0 and .255 addresses, possibly m aking t he process m ore efficient and less noisy. This sect ion describes anot her m apping at t em pt using t he echo request and revisit s t he net work- based broadcast in m ore det ail. H ost Sca n Usin g UD P Ech o Re qu e st s I n t he following t race, t he at t acker is t arget ing m ult iple net work addresses. Two were det ect ed by t his sensor const ellat ion, but it is very probable t here were m any m ore. By int erleaving t he scan, t he at t acker has m anaged t o space t he UDP echo request s far enough apart t hat t he probe will not be det ect ed by m ost scan det ect codes. The scram bled addresses are also a nice t ouch. The udp 6 refers t o UDP payload wit h 6 byt es of dat a. As discussed in t he last sect ion in t his chapt er,

st ealt h in int rusion det ect ion has a fairly specific m eaning, but I consider t he low and slow approach t he best st ealt h t echnique. Here is t he t race:

02:08:48.088681 02:15:04.539055 02:15:13.155988 02:22:38.573703 02:27:07.867063 02:30:38.220795 02:49:31.024008 02:49:55.547694 03:00:19.447808

slowpoke.mappem.com.3066 slowpoke.mappem.com.3066 slowpoke.mappem.com.3066 slowpoke.mappem.com.3066 slowpoke.mappem.com.3066 slowpoke.mappem.com.3066 slowpoke.mappem.com.3066 slowpoke.mappem.com.3066 slowpoke.mappem.com.3066

> > > > > > > > >

192.168.134.117.echo: udp 6 172.31.73.1.echo: udp 6 172.31.16.152.echo: udp 6 192.168.91.18.echo: udp 6 172.31.2.176.echo: udp 6 192.168.5.103.echo: udp 6 172.31.152.254.echo: udp 6 192.168.219.32.echo: udp 6 172.31.158.86.echo: udp 6

I nst ead of relying on t he I CMP echo request t o find host s, t his scan is seeing whet her any host will reply on t he echo port . The echo port echoes back ( im agine t hat ) any charact ers sent t o it . Good syst em adm inist rat ors should not have t his port list ening and good net work adm inist rat ors should not allow in t raffic t o t his port .

A W or d Abou t D e t e ct in g Sca n s Unt il som e brilliant researcher com es up wit h a bet t er t echnique, scan det ect ion boils down t o t est ing for X event s of int erest across a Y- sized t im e window. An int rusion- det ect ion syst em can and should have m ore t han one scan det ect window. For inst ance, we have seen several scans t hat exceed five event s per second. By using a short t im e window in t he range of one t o t hree seconds, t he syst em can det ect a high- speed scan and alert in near real- t im e, t hree t o five seconds aft er t he scan begins. Nipping such scans in t he bud is one of t he best uses of aut om at ed react ion. The next reasonable t im e window is on t he order of one t o five m inut es. This det ect s slower but st ill obvious scans. The Shadow int rusion- det ect ion syst em has had som e success wit h a scan det ect of five t o seven connect ions t o different host s over a one- hour window. I developed code t hat was enhanced by Bill Ralph t hat im plem ent ed a scan det ect process designed t o exam ine a 24- hour t im e window t o invest igat e t he TCP half- open scans and m ildly low and slow scans. Now t hat m ost int rusion det ect ion syst em s feed dat abases, a m aj or focus of console developm ent is det ect ion of low and slow scans. Scans have been det ect ed using dat abase queries wit h rat es as low as five packet s from a single I P address over 60 days. A scan rat e t hat low m akes sense only if it is int erleaved ( execut ed in parallel from m ult iple source addresses) t o t he ext rem e. We have docum ent ed scans of about 2,500 host s working t oget her and t he ent ire w32.leaves worm net work was about 30,000 com prom ised host s, so dist ribut ed slow scans are in t he hands of at t ackers.

N e t m a sk - Ba se d Br oa dca st s Which of t he echo request s in t he following t race are broadcast s? All of t hem ! We all recognize t he 0 and t he 255, but t hey are all broadcast packet s under t he right condit ions, and t he point of t his t race is t o t est for t hese condit ions. What are t hese right condit ions? They are net works t hat have a different subnet m ask t han t he usual one. Take a look:

02:21:06.700002 02:21:06.714882 02:21:06.715229 02:21:06.715561 02:21:06.716021 02:21:06.746119 02:21:06.746487 02:21:06.746845

pinger> pinger> pinger> pinger> pinger> pinger> pinger> pinger>

172.20.64.0: icmp: echo request 172.20.64.64: icmp: echo request 172.20.64.63: icmp: echo request 172.20.64.127: icmp: echo request 172.20.64.128: icmp: echo request 172.20.64.191: icmp: echo request 172.20.64.192: icmp: echo request 172.20.64.255: icmp: echo request

I once worked in a facilit y t hat charged for net work addresses. A single host address was $50/ m ont h and a subnet wit h a net m ask of 255.255.255.0, or 256 possible addresses, was $1,000/ m ont h. The facilit y had a Class B address space assigned t o it , 172.29.0.0, which t hey broke up int o subnet s. I t t urns out t hat if we bought a rout er and leased a subnet from t hem , we could bring our address space t ax way down. Here is how. Rent one subnet 172.29.15.0 for $1,000/ m ont h. The expect ed subnet m ask would be 255.255.255.0. That gives us 256 possible addresses, but 0 and 255 are not usable for host s, so t hat leaves 254 usable addresses. At $50/ m ont h, t hat is $12,700/ m ont h; so get t ing t he subnet for $1,000/ m ont h is already a big win. Wit h our own rout er, however, we could m ake t he subnet m ask anyt hing we want ed on " our" side of t he rout er. Suppose we could find t hree m ore sm all groups as cheap, er frugal, and ruggedly individual as we are. We could use 2 bit s of our address space for int ernal subnet s t o creat e four subnet s wit h 6 bit s of address space each. 2 6 is 64. The net m ask for t his is 255.255.255.192, or in hex 0xffffffc0. We could each have our own subnet t o do wit h as we please and split t he $1000/ m ont h for j ust a lit t le m ore t han t he price of five individual addresses. Great , but what is t he broadcast value for a subnet m ask of 255.255.255.192? 255 – 192 = 63, which is t he broadcast value for an " all 1s" broadcast , which m eans 0 or 64 is t he value for an " all 0s." I f t hat is t oo easy, however, consider t his:

c

0

in hex is

1100 ^^ ^^

0000 in binary. the two high order bits were lost to the NETID ^^^^ so we have 6 bits of host ID to play with

6 bit s all set t o 1s = 32 + 16 + 8 + 4 + 2 + 1 = 63. Now, t he pat t ern we see in t he t race above is an I CMP echo request t o 0, 64, 63, 127, 128, 191, 192, and 255. Could 127 and 128 also be broadcast s? Sure, if we have a sit uat ion in which we need lot s of subnet s, but each one can have a lower num ber of host s if we can st eal 1 bit from t he HOSTI D space and use it for subnet s. I f we use 25 bit s for t he NETI D ( 33,554,432 possible subnet s) each wit h 7 bit s of HOSTI D space ( 128 possible addresses) , t his would be a subnet m ask of 255.255.255.128. What is t he broadcast address? 255 – 128 = 127. 127 is t he " all 1s" broadcast . Could 191 and 192 also be broadcast s? I f we have a sit uat ion in which we need lot s and lot s of subnet s, but each one can have a low num ber of host s, we can use 27 bit s for t he NETI D ( 134,217,728 possible subnet s) each wit h 5 bit s of HOSTI D space ( 32 possible addresses) . This is a subnet m ask of 255.255.255.64. 255 – 64 = 191. Of course if we allow I CMP in, t hey could j ust send one packet wit h an I CMP net m ask request and be done wit h it ! I f t he sit e answers a net m ask request , it ret urns t he net work m ask t hat it is using, elim inat ing t he guesswork. Por t Sca n Tim e for an easier t race. The following t race is a basic port scan. Aft er our at t acker has found a host , he m ay want t o scan it t o see what services are act ive. This t race is TCP, and t he scan count s down on t he dest inat ion port . The skips in t he source port s are int erest ing. This m ay be a very busy m achine or m ore t han one scan m ay be going on. This is a good exam ple of a burst y t race; com pare t he arrival t im es at t he beginning of t he t race t o t he end. I n t he beginning of t he t race, t here is a lower num ber of packet s per second arriving t han at t he end. Any num ber of fact ors can influence t his. I f we can correlat e t his t race t o ot her t races from ot her sensor syst em s and t hey are also burst y, however, we can begin t o m ake som e assum pt ions about t he source m achine. The skipped source port s indicat e t he source of t he burst iness m ay be t he source com put er and not t he net work in bet ween. I f we can m at ch up t he source port s of our det ect wit h a det ect from anot her sensor, we m ay be able t o m ake assum pt ions as t o whet her m ult iple scans are occurring, or whet her t his scan is being init iat ed from a busy m ult iple- user com put er. The t race follows:

09:52:25.349706 bad.guy.org.1797 > target.mynetwork.com.12: S 09:52:25.375756 bad.guy.org.1798 > target.mynetwork.com.11: S

09:52:26.573678 09:52:26.603163 09:52:28.639922 09:52:28.668172 09:52:32.749958 09:52:32.772739 09:52:32.802331 09:52:32.824582 09:52:32.850126 09:52:32.871856

bad.guy.org.1800 bad.guy.org.1802 bad.guy.org.1804 bad.guy.org.1806 bad.guy.org.1808 bad.guy.org.1809 bad.guy.org.1810 bad.guy.org.1812 bad.guy.org.1814 bad.guy.org.1816

> > > > > > > > > >

target.mynetwork.com.10: S target.mynetwork.com.9: S target.mynetwork.com.8: S target.mynetwork.com.7: S target.mynetwork.com.6: S target.mynetwork.com.5: S target.mynetwork.com.4: S target.mynetwork.com.3: S target.mynetwork.com.2: S target.mynetwork.com.1: S

Sca n n in g for a Pa r t icu la r Por t So what service runs on TCP 7306? Durned if I know. As I m ent ioned in Appendix A, it never hurt s t o ask ht t p: / / www.google.com / , because all of t he port list s I have looked at are incom plet e. This t race was collect ed in lat e Decem ber 1998, which was t he beginning of a num ber of int erest ing scans t hat all seem ed t o be t arget ing st range port s. This scan is well craft ed; t here is no obvious signat ure. The first and last packet in t he following t race resolve t o a host nam e; t he m iddle four don't , as is obvious from t he fact t hat t he I nt ernet address is shown for t hese rat her t han a nam e. This can indicat e t hat t he at t acker is " shoot ing in t he dark," t hat he does not have an accurat e net work m ap. Oft en a reason som e nam es do not resolve is t hat t hey don't exist . Take a m inut e t o look at t he last packet in t he t race; source port s usually increase, but t his decreases by 22. Because t he init ial sequence num ber ( 49684211) is also lower, t his packet probably got lost along t he way and arrived out of order:

09:54:40.930504 8192 (DF) 09:54:40.940663 8192 (DF) 09:54:41.434196 8192 (DF) 09:54:41.442674 8192 (DF) 09:54:41.451029 8192 (DF) 09:54:41.451049 8192 (DF)

prober.3794 > lula.arpa.net.7306: S 49684444:49684444(0) win prober.3795 > 192.168.21.20.7306: S 49684454:49684454(0) win prober.3796 > 192.168.21.21.7306: S 49684945:49684945(0) win prober.3797 > 192.168.21.22.7306: S 49684955:49684955(0) win prober.3798 > 192.168.21.23.7306: S 49684965:49684965(0) win prober.3776 > host.arpa.net.7306: S 49684211:49684211(0) win

Com ple x Scr ipt , Possible Com pr om ise The next t race is com prised of m ult iple individual probes and at t acks. I t is shown here in five part s. The accesses t o port m ap ( SUNRPC) im ply t his at t acker is at t em pt ing a com prom ise or gat hering int elligence. Furt her, t he syst em answers back, which is a bad t hing. Port m ap should be blocked by t he filt ering rout er or firewall, and secure port m ap code should be on any syst em t hat runs SUNRPC. Not e t hat t hese at t acks are direct ed against t wo syst em s: host 16 and host 17. From t he port s accessed, I assum e t hese are UNI X syst em s. I t is quit e possible

t hat t hese t wo syst em s have a t rust relat ionship so t hat if one falls, t hey bot h fall. Then we see t he access t o TCP port 906, which is unassigned, and t he t arget syst em answers back. This could well indicat e t hat m alicious code has been inst alled on t he syst em . I nst ead of sending or receiving dat a, however, t he at t acker closes t he connect ion. Two hours lat er, t he at t acker pings t o see whet her t he syst em s are st ill t here. Take a look:

00:35:33.944789 00:35:33.953524 00:35:33.984029 00:35:33.991220

prober.839 > 172.20.167.16.sunrpc: 172.20.167.16.sunrpc > prober.839: prober.840 > 172.20.167.17.sunrpc: 172.20.167.17.sunrpc > prober.840:

udp udp udp udp

56 28 56 28

00:35:34.046598 prober.840 > 172.20.167.16.906: S 2450350587:2450350587(0) win 512 00:35:34.051510 172.20.167.16.906 > prober.840: S 1996992000:1996992000(0) ack 2450350588 win 32768 (DF) 00:35:34.083949 prober.843 > 172.20.167.17.sunrpc: udp 56 00:35:34.089272 172.20.167.17.sunrpc > prober.843: udp 28 00:35:34.279472 prober.840 > 172.20.167.16.906: F 117:117(0) ack 69 win 32120 00:35:34.284670 172.20.167.16.906 > prober.840: F 69:69(0) ack 118 win 32768 (DF) 02:40:43.977118 prober > 172.20.167.16: icmp: echo request 02:40:43.985138 172.20.167.16 > prober: icmp: echo reply

The preceding t race is fairly significant , and as an analyst I would be concerned and recom m end furt her invest igat ion. Let 's t alk about response for a m inut e. We want t o back up, invest igat e, cont ain, and clean. I f t hese were m y syst em s, I would direct t he following: z

Take your hands off t he keyboard and keep t hem off.

z

Pull t he net work cable im m ediat ely; we will be right t here.

z

z

Aft er you are on t he scene, one of your t op priorit ies is t o back up t he syst em ( s) . Treat t he backup t ape as evidence.

The port 906 bears furt her invest igat ion. The easiest t hing t o do is bring a lapt op and a sm all hub t o t he syst em you expect m ay be com prom ised. Plug t he lapt op and one of t he possibly com prom ised syst em s int o t he hub. Then, load your own copies of syst em ut ilit ies ( ls, ps, net st at , for exam ple) int o a direct ory on t he suspect syst em and set your pat h t o t hat direct ory, or get t hem from a CD t hat you have creat ed. From t he lapt op, t elnet t o t he possibly com prom ised syst em on port 906. Run your versions of net st at and ps and such on t he suspect syst em t o

see what is act ive. Also, exam ine t he .rhost s and / et c/ host s.equiv on t he suspect syst em t o see what ot her syst em s are t rust ed by our dynam ic duo.

An Alt e r n a t ive Appr oa ch There is no way I can do j ust ice t o incident handling in a few paragraphs. I ncident Handling St ep by St ep is a collaborat ion of m ore t han 90 incident handlers. I t is available from ht t p: / / www.sans.org/ . One best pract ice t echnique if t he syst em is down, or m ust be reboot ed, is t o use a boot able CD- ROM. Then, you can m ount t he syst em disk as a dat a drive. I f at all possible, keep t he original hard drive as evidence. When you are finally sat isfied t hat you underst and what is going on wit h port 906, unless you are t ot ally cert ain t he syst em was not com prom ised, t he following is t he best course of act ion. Turn t o t he syst em owners and ask when t he last full backup was m ade. Make sym pat het ic clucking noises as t hey say " never" or " t wo years ago" and nod your head sadly. Look t hem in t he eye and ask whet her any dat a absolut ely m ust be saved. Back up dat a files only, form at t he hard drive, and t ell t hem t o be sure t o inst all all t he appropriat e securit y pat ches before put t ing t he syst em back in business. Hook your lapt op t o t he local area net work. Scan t he local net for SUNRPC and also for syst em s t hat answer on port 906, what ever else you have learned. Cont inue nuking from high orbit unt il t he infect ion is sanit ized. Does t his sound draconian? The deat h of a t housand cut s is far worse. By t he way, we have t alked about Loki and dist ribut ed denial of service t ools like Trinoo using echo request s and replies for ot her purposes. Perhaps you would want t o t ake a close look at t he cont ent of t hat ping in t he t race as well. " Ra n dom " Por t Sca n This scan was well on it s way t o set t ing a speed record. This is anot her exam ple of scanning port s t hat don't m ake any sense. There is no det ect able signat ure; t he purpose of t he scan is unknown:

11:48:42.413036 win 512 11:48:42.415953 win 512 11:48:42.416116 win 512 11:48:42.416279 win 512 11:48:42.416443 win 512

prober.18985 > host.arpa.net.794: S 1240987936:1240987936(0) prober.18987 > host.arpa.net.248: S 909993377:909993377(0) prober.19031 > host.arpa.net.386: S 1712430684:1712430684(0) prober.19032 > host.arpa.net.828: S 323265067:323265067(0) prober.19033 > host.arpa.net.652: S 1333164003:1333164003(0)

11:48:42.556849 win 512 11:48:42.560124 win 512 11:48:42.560824 win 512 11:48:42.561313 win 512 11:48:42.561437 win 512 11:48:42.561599 win 512 11:48:42.563074 win 512 11:48:42.563115 win 512 11:48:42.563238 win 512 11:48:42.565041 win 512

prober.19149 > host.arpa.net.145: S 2112498338:2112498338(0) prober.19150 > host.arpa.net.228: S 1832011492:1832011492(0) prober.19151 > host.arpa.net.840: S 3231869397:3231869397(0) prober.19152 > host.arpa.net.1003: S 2435718521:2435718521(0) prober.19153 > host.arpa.net.6: S 2632531476:2632531476(0) prober.19165 > host.arpa.net.280: S 2799050175:2799050175(0) prober.19166 > host.arpa.net.845: S 2065507088:2065507088(0) prober.19226 > host.arpa.net.653: S 1198658558:1198658558(0) prober.19227 > host.arpa.net.444: S 1090444266:1090444266(0) prober.19274 > host.arpa.net.907: S 2414364472:2414364472(0)

Okay, we don't know t he purpose of t he scan, and t hat is frust rat ing. So as an analyst , what do we know about t his? We know it is fast and we know t hat t he source port behavior is unpredict able—som et im es it skips, and som et im es it doesn't . Why doesn't t he t race m ake sense? Why in t he world is som eone scanning so m any unknown port s? I am not sure t hat we will ever know t hese answers. I n t he past few years, t here have been a lot of very odd scan pat t erns. The best guess I have is t hat som eone was using nm ap, hping2, isic, packet x, or a sim ilar t ool t o craft scans t hat had no possible purpose, probably from spoofed source addresses. That answers how, but not why! Here is a guess: t o drive int rusion- det ect ion analyst s crazy; t o see what t hey would report and what t hey wouldn't ; t o see whet her t he scanners could cause a CNN news report t hat t he world was under som e horrid new cyber at t ack. Grant ed, it is far fet ched, but it is t he best I can com e up wit h. How should t he analyst react t o t his t race and ot her unknown seem ingly random scans? I do recom m end report ing st uff like t his, because you never know what piece of inform at ion will help your CI RT. I f your firewall is set t o deny everyt hing not specifically allowed, and none of your host s answer back, however, don't get st ressed. The best idea is t o creat e a direct ory nam ed " Scans_From _Mars" and file t hese det ect s t here. D a t a ba se Cor r e la t ion Re por t I am a st rong fan of allowing analyst s t o " fire and forget " —t hat is, when t hey see a det ect , j ust report it and m ove on. When we first st art ed doing fairly large- scale int rusion det ect ion ( five sit es, 12,000 com put ers or so) , t he analyst had t o m anually check all t he sensors for a correlat ion of source port , source I P, dest inat ion port , dest inat ion I P, and so on. Back t hen, if you were looking for som et hing like correlat ion of TTL field or som e behavior of t he sequence num ber, it m ight t ake days t o sort it out .

Life is t oo short for t hat kind of m adness. Aft er a pat t ern has been det ect ed and report ed, t he dat abase looks t o see whet her any correlat ions exist . This is what such a report m ight look like. This report was generat ed by a m ilit ary correlat ion syst em known as Dark Shadow. I t is based on an Oracle dat abase. When an analyst det ect s and report s an int rusion at t em pt , Dark Shadow checks for t hat pat t ern across it s dat a window of X sensor locat ions for Y m ont hs. I f it finds a m at ch, it creat es a correlat ion report . This is why t he analyst can operat e in a fireand- forget m ode. Not e t hat from t he source port ranges, it appears t hat t wo processes are running ( dest inat ion port 111 is cont act ed by source port s from 617–1023, and dest inat ion port 25 by port s 2294–29419) on scanner, one t o check em ail and t he ot her t o check port m apper. The t wo processes are probably bound by a shell script and reading from a file of t arget I P addresses. The probabilit y is very high t hat t his scan is int erleaved across m any m ore addresses. Here it is:

06/04/98 06/04/98 06/04/98 06/04/98 06/04/98 06/04/98 06/04/98 06/04/98 06/04/98 06/04/98 06/04/98 06/04/98 06/04/98 06/04/98 06/04/98

03:20:25 04:02:35 04:02:36 04:06:04 04:09:15 07:24:47 07:28:06 07:28:21 07:31:40 12:46:21 12:49:40 16:05:22 16:08:33 16:08:52 16:08:53

scanner scanner scanner scanner scanner scanner scanner scanner scanner scanner scanner scanner scanner scanner scanner

622 21091 890 21242 617 2295 1017 2333 729 20553 1023 29276 803 29419 900

172.20.1.41 172.20.1.1 172.20.1.1 172.20.10.114 172.20.10.114 192.168.229.18 192.168.229.18 172.20.1.41 172.20.1.41 172.20.48.157 172.20.48.157 172.20.1.1 172.20.1.1 172.20.10.114 172.20.10.114

111 25 111 25 111 25 111 25 111 25 111 25 111 25 111

t t t t t t t t t t t t t t t

SN M P/ I CM P The Sim ple Net work Managem ent Prot ocol ( SNMP) , even before t he exploit s t hat followed t he release of t he PROTOS t oolkit in early 2002, could provide an at t acker wit h a lot of inform at ion about your host s and net work configurat ion. According t o t he RFC NSMP is port 161 TCP and UDP. I have never seen a TCP version of SNMP in pract ice, but for safet y, ) port 161 TCP and UDP should be blocked from t he I nt ernet . I t is am azing how m any devices, such as m icro hubs, x- t erm inals, and print ers, have SNMP agent s. By default , t hese devices are prot ect ed by a well- known password ( com m unit y st ring) , t ypically " public." Many securit y- conscious organizat ions change t his password, usually t o one of t he following: z

Privat e

z

I nt ernal

z

The nam e of t he organizat ion

Not e: Forgive m e if you t hought I was serious. The choices of privat e, int ernal, or t he nam e of t he organizat ion for SNMP com m unit y st rings are not advised. Pick som et hing hard t o guess. I n t he following t race, not ice t he use of broadcast for bot h SNMP and I CMP. This is a very effect ive m apping t echnique because t he at t acker doesn't have t o send m any packet s t o pot ent ially collect a lot of inform at ion.

17:31:33.49 17:31:33.73 17:31:33.73 ... 17:43:17.32 17:43:17.32

prober.1030 > 192.168.2.255.161: GetNextRequest(11)[|snmp] prober.1030 > 255.255.255.255.161: GetNextRequest(11)[|snmp] prober > 255.255.255.255: icmp: echo request prober > 192.168.1.255: icmp: echo request prober.1030 > 192.168.1.255.161: GetNextRequest(11)[|snmp]

FTP Bou n ce We have anot her t race court esy of t he correlat ion dat abase engine. I n t his case, t he analyst is searching for FTP- DATA ( TCP port 20) wit hout an init iat ing FTP ( TCP port 21) . This can be t he result of FTP bounce. The advant age t o t he at t acker of using FTP bounce is t hat his ident it y is hidden. This is j ust like using an open proxy server, except t hat t he source port will always show as TCP 20 for FTP- DATA. To do t his, t hey j ust log on t o a vulnerable FTP server as anonym ous and open up arbit rary port s t o probe t he int ended vict im . This is not usually a very serious t hreat , unless t he FTP server is a t rust ed host by it s organizat ion. Then, an at t acker m ay be able t o use t he FTP server t o probe t he organizat ion. FTP bounce is t he subj ect of a CERT advisory, which you can find at www.cert .org/ ft p/ cert _advisories/ CA- 97.27.FTP_bounce. I n som e im plem ent at ions of FTP daem ons, t he PORT com m and can be m isused t o open a connect ion t o a port of t he at t acker's choosing on a m achine t hat t he at t acker could not have accessed direct ly. There have been ongoing discussions about t his problem ( called " FTP bounce" ) for several years, and som e vendors have developed solut ions for t his problem . When we uncovered t he t raffic in t he following t race, we went back t o prober and it was an FTP server, it support ed anonym ous FTP, and we were able t o use t he port com m and as advert ised. The int erest ing t hing is t his t race was det ect ed long before going t o unknown port s becam e a fad. The following t race represent s all t he connect ions from prober t o t he prot ect ed net work ( 172.20.152) :

date time 04/27/98 10:17:31 04/27/98 10:27:32

source IP prober prober

src port dest IP 20 172.20.152.2 20 172.20.152.2

dest port 3062 t 4466 t

05/06/98 05/06/98 05/06/98 05/06/98

prober prober prober prober

20 20 20 20

1363 4814 1183 1544

06:34:22 09:12:15 09:15:07 10:11:30

172.20.152.2 172.20.152.2 172.20.152.2 172.20.152.2

t t t t

N e t BI OS- Spe cific Tr a ce s This sect ion exam ines som e t races t hat appear t o be t arget ed at Windows syst em s. Net BI OS uses 135–139 TCP and UDP. I t is cert ainly t rue t hat ot her syst em s t han Windows use Net BI OS ( SAMBA, for exam ple) , but as a general rule Net BI OS t raffic can be expect ed t o be generat ed by and t arget ed against Windows syst em s. A Visit fr om a W e b Se r ve r One of t he charact erist ics of Net BI OS is t hat t raffic t o dest inat ion port UDP 137 is oft en caused by som et hing a sit e init iat es. I f you send em ail t o a sit e running Microsoft Exchange, for exam ple, t he sit e will oft en send a port 137 at t em pt back. The following t race t urned up because we saw 137s and t hen we st art ed searching for t he cause fact or. To find t he answer, we pulled all t raffic for j ellypc and found t he web access. Then, we did t he sam e for j am pc and it was t he sam e pat t ern. Being able t o pull all t he t raffic for a host is very valuable when doing analysis. I f your I DS does not support t his, beat on your vendor!

Pu blic Sa fe t y An n ou n ce m e n t Alt hough t his sect ion focuses m ost ly on Net BI OS, let m e t ake a m inut e t o m ent ion t hat t here are host ile web servers on t he I nt ernet . When a syst em from your sit e visit s a web server, t hat server can collect a lot of inform at ion about you, including your operat ing syst em and browser version. I f your sit e doesn't use Net work Address Translat ion ( NAT) , t he web server will have your I P address. I t is oft en possible t o ext ract t he web client 's em ail address. Som e sit es open a connect ion back t o t he client and perform what we believe is TCP st ack analysis. ( And we haven't even discussed cookies.) The web server in t he j ellypc t race wasn't sat isfied wit h j ust t he inform at ion it could collect from t he HTTP headers; t he server want ed m ore, so anot her syst em from t he sam e subnet com es back t o t he host s t hat visit ed t he web server t o collect t he inform at ion available from t he Net BI OS Nam e Service. Here is t he pat t ern:

12/02/97 08:27:18 12/02/97 08:27:19 12/02/97 17:06:03 12/02/97 17:08:10

jellypc.arpa.net 1112 -> www.com http 0 bill.com 137 -> jellypc.arpa.net jampc.arpa.net 2360 -> www.com http 0 bill.com 137 -> jampc.arpa.net

137

137

I got on t he phone and had a great chat wit h a t echnical t ype who runs t he net work t here. I t t urns out t hat t hey are using a piece of com m ercial soft ware for m arket ing purposes t hat creat es a com prehensive dat abase of your likes and dislikes. I f you want t o see what kind of inform at ion is available about a part icular Microsoft Windows host , t he com m and is called nbt st at and it runs on Windows NT syst em s. A Windows host t hat runs Net BI OS cannot refuse t o answer an nbt st at . A sam ple t race is shown here:

C:\>nbtstat -a goo NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------Registered Registered Registered MAC Address = 00-60-97-C9-35-53 GOO

GOO

KD2

KD2

KD2

GOO

SRN0RTH

INet~Services IS~GOO

KD2

KD2

..__MSBROWSE__.

UNIQUE UNIQUE GROUP GROUP UNIQUE UNIQUE UNIQUE GROUP UNIQUE GROUP UNIQUE GROUP

The Net BI OS nam e of m y m achine, Goo, can be picked up as well as m y workgroup, KD2. The logon nam e I use on t hat m achine is srnort h. I t is also possible t o det erm ine t hat I have a m ast er browser cookie. Perhaps t his applicat ion of t he wildcard request doesn't concern you, but I have been able t o use nbt st at queries t o det erm ine an ent ire organizat ional st ruct ure as well as m ost of t he logon nam es. N u ll Se ssion But wait , t here's m ore. Null sessioning has been described as analogous t o finger. I n essence, it is logging on t o a syst em as a nobody user. Alt hough you cannot m odify anyt hing, you can learn about t he syst em . A sam ple com m and st ring is as

follows:

net use \\172.20.244.164\IPC$ "" /USER:""

This generat es lit erally pages of inform at ion, a sect ion of which is shown here:

2/18/98 1:39 AM - Jsmith - \\192.168.4.22 UserName Administrator Groups,Administrators (Local, Members can fully administer the computer/domain) AccountType,User HomeDrive HomeDir PswdCanBeChanged,Yes PswdLastSetTime,Never PswdRequired,Yes PswdExpires,No AcctDisabled,No AcctLockedOut,No AcctExpiresTime,Never LastLogonTime,11/20/98 3:24 PM LastLogonServer,192.168.4.22 Sid,S-1-5-21-706837240-361788889-398547282-500

Null sessioning can be prevent ed on Windows 2000 and if you will give m e a second, I will t est it on Windows XP Professional. Yup, it works—Cont rol Panel, Adm inist rat ive Tools, Local Securit y Policy.

St e a lt h At t a ck s The first t im e I heard t he t erm st ealt h was in a paper by Chris Klaus t it led " St ealt h Scanning—Bypassing Firewalls/ SATAN Det ect ors." He was describing what people now usually refer t o as " half open" —t hat is, int ent ionally violat ing t he TCP t hreeway handshake. There are a num ber of variat ions of half scans, and we are going t o exam ine all t he com m on ones. These are not all t hat hard t o det ect in and of t hem selves, but as you will learn in t he discussion on coordinat ed at t acks, t hey are get t ing som e help. Nowadays, som e folks use st ealt h t o m ean null flags ( no flags or code bit s set ) . The only approaches I find act ually st ealt hy are t hose based on eit her low and slow, or highly dist ribut ed, packet delivery. As t im e goes on, st at ic packet filt ers cont inue t o be less and less com m on; half- open scans are less and less an issue. They cert ainly should not be called st ealt h because t hey st and out like a sore t hum b. The Snort web page, ht t p: / / www.snort .org/ , list s a num ber of effect ive rules t o det ect t hese probes. This is a season of advanced scans; at t ackers wit h t he skill t o t ype, m ake, and

act ually com pile soft ware are using t ools t hat give t hem t he look and feel of " eleet ness." Three years ago it was j ackal; at t he t urn of t he cent ury, hping and nm ap; and t oday, dist ribut ed scanners. I n t he book, I nside Firewalls by Robert Ziegler ( New Riders) , I com m ent ed t hat I cont inue t o be ast ounded by t he securit y provided by Net work Address Translat ion ( NAT) . My m ost im port ant files are on a vm ware version of Linux 7.2 on m y Windows lapt op, and t he Linux syst em is behind a NAT. So, if at t ackers can get t hrough m y hom e perim et er defenses, which also include a NAT, and break int o m y XP lapt op, t hey st ill have anot her NAT t o go t hrough. Wit h appliance firewalls available as cheap as $300, you can afford a num ber of NATs in your organizat ion, which will foil m ost of t his scanning. There is also a st rong argum ent t hat not hing penet rat es a well- configured, proxy- based firewall ( alt hough we will disput e t his in a m om ent ) . None of t he decept ion t ools will elude a well- t rained analyst wit h an I DS t hat collect s all t he t raffic and has a support ing dat abase. I f your sit e has chosen a lesser pat h, you m ay be in for a wild ride. As we get ready t o launch int o som e t races of st ealt h t echniques, t ake a m inut e t o read t he opening com m ent from t he original 1997 j ackal.c source code. / * Jackal - St ealt h/ FireWall scanner. Wit h t he use of halfopen port s and sending SYNC ( som et im es addit ional flags like FI N) one can scan behind a firewall. And it shouldnt let t he sit e feel we're scanning by not doing a 3- way - handshake we hope t o avoid any t cplogging. Credit s: Halflife, Jeff ( Phij i) Fay, Abdullah Marafie. Alpha Test er: Walt er Kopecky. Result s: Som e firewalls did allow SYN | FI N t o pass t hrough. No Sit e has been able t o log t he connect ions t hough during alpha t est ing. ShadowS shadows@kuwait .net Copyleft ( hack it i realy dont care) . * / I t was a brilliant idea! I f t he filt ering rout er t est s for SYN, feed it a SYN/ FI N. However, t he st at em ent t hat j ackal had never been logged by any sit e m isses t he m ark. I n Appendix A, "Exploit s and Scans t o Apply Exploit s," you saw t he I MAP t races wit h t he SYN/ FI N set , which were det ect ed by t he Shadow syst em . Com pet ent int rusion- det ect ion syst em s were able t o log and analyze anyt hing sent by j ackal ( or hping or nm ap) . I n fact , t oday when at t ackers set SYN/ FI N, t hey m ake our j ob easy. Ex plicit St e a lt h M a ppin g Te ch n iqu e s The t wo well- known explicit m apping t echniques are t he SYN/ ACK and t he FI N scan. Bot h of t hese generat e a RESET, if t hey hit an act ive host . They also get an I CMP error m essage back if t he host is unreachable. Explicit st ealt h m apping is m ore efficient t han inverse m apping ( described lat er) , but is possibly m ore obvious. FI N Sca n

I have never det ect ed a FI N scan in t he wild and have chosen not t o sim ulat e one. I n t he case of a FI N scan, one would det ect a large num ber of packet s wit h t he FI N flag set where t here was no t hree- way handshake ever est ablished. We have already discussed using a dat abase t o find FTP bounce. A good int rusion- analysis syst em should provide t he capabilit y t o look for spurious t raffic such as FI Ns, t o connect ions t hat were never est ablished. I have seen ACKs only and have seen t hem penet rat e a Check Point firewall. I n v e r se M a ppin g

I nverse m apping t echniques can com pile a list of net works, or host s, t hat are not reachable and t hen use t he converse of t hat m ap t o det erm ine where t hings probably are. We will also show a DNS exam ple of all replies and no queries. Before we go on, t hough, if you absolut ely cannot do NAT and m ust use public I P addresses, m ake sure you do not allow I CMP unreachables out of your net work. That will not st op all inverse m apping t echniques, but it will quench a large num ber of t hem . As you look at t he t race t hat follows, keep t his in m ind: t he answers by rout er.m ynet .net are doing all t he harm :

02:58:05.490 stealth.mappem.com.25984 > 172.30.69.23.2271: R 0:0(0) ack 674719802 win 0 02:59:11.208 stealth.mappem.com.50620 > 172.16.7.158.1050: R 0:0(0) ack 674719802 win 0 02:59:20.670 stealth.mappem.com.19801 > 192.168.184.174.1478: R 0:0(0) ack 674719802 win 0 02:59:31.056 stealth.mappem.com.7960 > 192.168.242.139.1728: R 0:0(0) ack 674719802 win 0 02:59:42.792 stealth.mappem.com.16106 > 172.16.102.105.1008: R 0:0(0) ack 674719802 win 0 03:00:50.308 stealth.mappem.com.8986 > 172.16.98.61.1456: R 0:0(0) ack 674719802 win 0 03:00:58.939 stealth.mappem.com.35124 > 192.168.182.171.1626: R 0:0(0) ack 674719802 win 0 03:00:58.940 router.mynet.net > stealth.mappem.com: icmp: host 192.168.182.171 unreachable An sw e r s t o D om a in Qu e r ie s

Anot her variat ion of inverse m apping is shown here. The probing com put er sends answers t o dom ain quest ions t hat were never asked. The goal is t o st um ble across a subnet or host t hat doesn't exist , which will generat e an I CMP unreachable m essage. As st at ed earlier, t his pat t ern t ends t o evade det ect ion. I t can be found wit h scan det ect code if t he at t acker get s greedy and probes t oo m any host s t oo quickly. I t can also be det ect ed by ret rospect ive analysis script s or dat abase searches for applicat ion st at e violat ions. Here is t he exam ple of inverse m apping:

05:55:36.515566 stealth.com.domain > 172.29.63.63.20479: udp

06:46:18.542999 07:36:32.713298 07:57:01.634613 09:55:28.728984 10:38:53.862779 10:40:37.513176 10:44:28.462431 11:35:40.489103

stealth.com.domain stealth.com.domain stealth.com.domain stealth.com.domain stealth.com.domain stealth.com.domain stealth.com.domain stealth.com.domain

> > > > > > > >

192.168.160.240.12793: udp 172.29.185.48.54358: udp 254.242.221.165.13043: udp 192.168.203.163.15253: udp 192.168.126.131.39915: udp 192.168.151.126.19038: udp 172.29.96.220.8479: udp 192.168.7.246.44451: udp

11:35:40.489103 stealth.com.domain > 192.168.7.246.44451: udp 11:35:40.489523 router.mynet.net > stealth.com: icmp: host 192.168.7.246 unreachable

Because I P spoofing, usually part of a denial- of- service at t ack, is so com m on, you m ay be asking, " Why isn't t he explanat ion for t his I P spoofing of t he 172.29, 192.168, and so fort h addresses and direct ing t hem t o st ealt h.com ?" Couldn't t his j ust be seeing t he echoes of t his act ivit y direct ed back t o our net work? The problem is t hat t his doesn't resem ble norm al DNS responses. I t doesn't have any indicat ions t hat som e kind of DNS query was issued. To invest igat e t his furt her, you m ight t ry t o find out whet her st ealt h.com is really a DNS server. You use t he nslookup com m and and change servers t o st ealt h.com and t ry t o resolve any address. I f it works, you know t hat st ealt h.com is a t rue DNS server and t he m yst ery int ensifies. ( Tragically, nslookup, at least on UNI X, is being deprecat ed by t he m ore obscure dig program .) I f it doesn't respond, chances are it is not a DNS server, and it really is t he aggressor. I t is also possible t hat it is a DNS server, but you m ight not have access t o it . An sw e r s t o D om a in Qu e r ie s, Pa r t 2

The following act ivit y is sim ilar t o what you j ust saw because bot h use source port of 53 or dom ain. This out put is TCP and cam e from m ult iple different sources, however, unlike t he preceding act ivit y. Any guesses about what is going on here?

11:19:30.885069 1024 11:17:29.375069 1024 11:15:32.115069 1024 11:11:17.485069 1024 11:09:12.945069 1024 12:01:05.060000 1024 12:03:24.820000 1024 12:06:12.620000 1024 12:09:09.940000 1024

host1.corecomm.net.53 > myhost1.com.21: S 7936:7936(0) win host1.corecomm.net.53 > myhost1.com.139: S 7936:7936(0) win host1.corecomm.net.53 > myhost1.com.23: S 7936:7936(0) win host1.corecomm.net.53 > myhost1.com.43981: S 7936:7936(0) win host1.corecomm.net.53 > myhost1.com.880: S 7936:7936(0) win host70.corecomm.net.53 > pc112.com.880: S 1738:1738(0) win host70.corecomm.net.53 > pc112.com.139: S 1738:1738(0) win host70.corecomm.net.53 > pc112.com.21: S 1738:1738(0) win host70.corecomm.net.53 > pc112.com.43981: S 1738:1738(0) win

12:09:57.960000 host70.corecomm.net.53 > pc112.com.23: S 1738:1738(0) win 1024

This appears t o be a scan of m yhost 1.com , pc112.com , and m any ot her host s not shown in t his abbreviat ed out put of som e com m on dest inat ion port s such as 21 ( FTP) , 23 ( t elnet ) , and 139 ( Net BI OS Session Manager) . But , t here are som e funky dest inat ion port s along wit h t hose com m on ones t hat aren't readily ident ifiable, such as 43981 and 880. You can round up all t he usual suspect explanat ions for t he unconvent ional port s, but in t his case, your analysis should concent rat e m ore on t he source port used. TCP source port 53 m ight be allowed int o m any net works because t his can be indicat ive of act ivit y from a long DNS response. Rem em ber from Chapt er 6, " DNS," t hat UDP DNS responses of m ore t han 512 byt es are reissued t o t he DNS server t o dest inat ion port TCP 53. When t he response ret urns t o your net work, t he source port will be 53 and you need t o allow t hat back in t o receive t hat response. A sm art net work adm inist rat or qualifies t his so t hat it is allowed back in only if it was est ablished inside t he net work of origin, and only if t he dest inat ion port is great er t han 1023 ( indicat ive of an ephem eral port ) , which is t he case in t he long DNS responses. That is not t he case in t he preceding scan, but t he scanner is banking on t he packet - filt ering device being open on source port 53 wit hout any furt her qualificat ion. This way, t he scanner m ight circum vent a norm ally prot ect ive packet - filt ering device. I t is int erest ing t o not e t hat t he TCP sequence num bers you see in t he scan are repeat ed for each of t he sam e source- t o- dest inat ion port scans. These should change for each new TCP segm ent creat ed. Anot her forensics t idbit about t his scan t hat is not obvious unless you look at m any m ore records t han are shown, gives som e insight int o t he nat ure of t he TCP sequence num ber craft ing. The preceding scan shows t wo TCP sequence num bers: 7936 and 1738. Considering t hat t he TCP sequence num ber field is 32 bit s long, t hese are very sm all init ial sequence num bers—quit e unusual. All t he TCP sequence num bers from t his scan were light weight , and when t he act ivit y was dum ped in hex, t he reason why was discovered. The high- order 16 bit s of t he TCP sequence num ber were always 0s. This is confirm at ion t hat som e kind of sequence num ber m anipulat ion was perform ed, and it becom es a signat ure of t his act ivit y. Fr a gm e n t s, Ju st Fr a gm e n t s

Consider t his final exam ple of an inverse m apping t echnique. As you have already learned, only t he first fragm ent chunk com es wit h prot ocol inform at ion. At t ackers using t his t echnique ( along wit h som e int erest ing variat ions) were able t o penet rat e older firewalls and filt ering rout ers. The firewalls would assum e t hat t his was j ust anot her segm ent of t raffic t hat had already passed t heir access list s. Needless t o say, t his has been fixed in m ost vendors' product s.

I n t his case, however, t he prober isn't part icularly int erest ed in firewall penet rat ion. Once again, if one of t he t arget host s does not exist , t he rout er sends back an unreachable m essage. The at t acker can t hen com pile a list of all t he host s t hat do not exist and, by t aking t he inverse of t hat list , has a list of t he host s t hat do exist . This is why t his class of t echniques is called inverse m apping. Take a look:

18:32:21.050033 18:32:21.109287 18:32:21.178342 18:32:21.295332 18:32:21.344322 18:32:21.384284 18:32:21.431136 18:32:21.478246 18:32:21.522631

PROBER PROBER PROBER PROBER PROBER PROBER PROBER PROBER PROBER

> > > > > > > > >

192.168.5.71: 192.168.5.72: 192.168.5.73: 192.168.5.74: 192.168.5.75: 192.168.5.76: 192.168.5.77: 192.168.5.78: 192.168.5.79:

(frag (frag (frag (frag (frag (frag (frag (frag (frag

9019:480@552) 9275:480@552) 9531:480@552) 9787:480@552) 10299:480@552) 10555:480@552) 11067:480@552) 11579:480@552) 11835:480@552)

M e a su r in g Re spon se Tim e Lat ely, we've seen a lot of t raffic com ing from all over t he place direct ed t o DNS servers, but not for t he purpose of querying for DNS inform at ion or ost ensibly of m alicious int ent . What is happening is t hat com panies have developed soft ware t hat t ries t o deliver t he best possible response t im e t o web request s. I t has been dem onst rat ed t hat m ost users will t olerat e about an eight - second delay in receiving responses and aft er t hat t hey m ight go t o a com pet it or sit e wit h bet t er response t im e. I t has becom e a m at t er of e- business survival and profit abilit y t o offer good response t im e, and because necessit y is t he m ot her of invent ion, soft ware has been creat ed t o accom plish t he m ission. The pat t erns explained in t his sect ion are from a product known as 3DNS. One t echnique is t o associat e t he user request wit h an aut horit at ive DNS server for t he user's host and find t he response t im e t o t he DNS server. This assum es t hat t he aut horit at ive DNS server and t he user's host s are geographically close, which m ight not always be t he case. Why not j ust find t he dist ance t o t he user's host ? I ndeed, t his seem s m ore logical, but m any sit es are well prot ect ed, and access t o t he user's host is not always available. They figure t here is a bet t er chance of having som e kind of access t o t he DNS server, which m ay or m ay not be t he case. There has been a lot of hue and cry from analyst s who see t heir I DS fired because of t he t raffic generat ed by t his soft ware. Many sit es feel violat ed because t raffic is direct ed t o t he sacred DNS server, of all host s. And, m any m ore sit es don't underst and what is happening and perceive t his act ivit y t o be an at t ack of som e sort . The final obj ect ion is t hat t his is unaut horized inform at ion gat hering, regardless of whet her it benefit s t he end user. Let 's t ake a look at som e of t he signat ures associat ed wit h t his t ype of t raffic. One

t hing t hat you should keep in m ind is t hat m any different web sit es use t his soft ware and so you will see m any different source I Ps. Because of t he unique signat ures generat ed from m ult iple source I Ps, t his has been m ist aken for som e kind of coordinat ed at t ack. As you will see, however, it really isn't . Ech o Re qu e st s No surprise wit h t he following TCPdum p act ivit y t o m easure response t im e t o your DNS server. The echo request is issued and t he response t im e is m easured based on receipt of an I CMP echo reply, if t here is one:

10:25:44.070000 10:25:44.070000 10:25:44.070000 10:30:01.530000 10:30:01.530000 10:30:01.550000 10:30:25.660000 10:30:25.660000 10:30:25.670000 10:32:12.520000

216.32.68.13 > mydns.com: icmp: echo request 216.32.68.13 > mydns.com: icmp: echo request 216.32.68.13 > mydns.com: icmp: echo request 216.32.68.13 > mydns.com: icmp: echo request 216.32.68.13 > mydns.com: icmp: echo request 216.32.68.13 > mydns.com: icmp: echo request 209.67.29.8 > mydns.com: icmp: echo request 209.67.29.8 > mydns.com: icmp: echo request 209.67.29.8 > mydns.com: icmp: echo request 209.67.78.200 > mydns.com: icmp: echo request

As you have learned, however, m any sit es block I CMP echo request s because I CMP has capabilit y t o m ap sit es bot h act ively wit h a ping, and also by elicit ing error m essages t hat give away t he posit ion of host s and rout ers in a sit e. And, if t his is t he case, an at t acker, or even a service provider using a t ool like 3DNS m ight focus t heir reconnaissance on t he DNS server. Act u a l D N S Qu e r ie s I f t he user's DNS server didn't respond t o t he I CMP echo request and t he server using t he 3DNS probing soft ware is configured t o cont inue t o t ry t o m ake cont act wit h t he DNS server, m ore act ivit y is sent , as shown here:

216.32.68.11.3200 > mydns.com.53: mydns.com.53 > 216.32.68.11.3200: 216.32.68.11.3201 > mydns.com.53: mydns.com.53 > 216.32.68.11.3201: 216.32.68.11.3202 > mydns.com.53: mydns.com.53 > 216.32.68.11.3202:

0 [0q] Type0 (Class 0)?. (36) 0 FormErr [0q] 0/0/0 (12) DF 256 [0q] Type0 (Class 0)? . (36) 0 FormErr [0q] 0/0/0 (12) DF 512 [0q] Type0 (Class 0)? . (36) 0 FormErr [0q] 0/0/0 (12) DF

A real DNS query is not issued, but one is sent t o UDP port 53 wit h a DNS m essage of all 0s. TCPdum p perform s som e int egrit y checking of t he DNS m essage and if it discovers what it considers t o be not ewort hy fields, it report s t hem . The 0q m eans t hat t here were zero queries in t he DNS m essage, for exam ple. Norm ally, for t ypes ot her t han inverse queries t here will be at least one query. That is why TCPdum p report ed it and all ot her 0- padded fields it considers

t o be odd. This elicit s an error response from m ydns.com , which is t hen used t o com put e t he round- t rip t im e. Pr obe on UD P Por t 3 3 4 3 4 Here is yet a t hird t ype of act ivit y direct ed at t he DNS server if t he ot hers have failed:

209.67.78.203.3310 > mydns.com.33434: udp 36 [ttl 1] 209.67.78.203.3311 > mydns.com.33434: udp 36 (ttl 2) 216.32.68.10.3307 > mydns.com.33434: udp 36 [ttl 1] 216.32.68.10.3308 > mydns.com.33434: udp 36 (ttl 2) 216.32.68.10.3307 > mydns.com.33434: udp 36 [ttl 1] 216.32.68.10.3308 > mydns.com.33434: udp 36 (ttl 2) 209.67.78.200.3411 > mydns.com.33434: udp 36 [ttl 1] 209.67.78.200.3412 > mydns.com.33434: udp 36 (ttl 2)

This out put is m uch like you m ight see wit h a UNI X t racerout e. Tracerout e has t he signat ure of at t em pt ing a UDP connect ion t o a high- num bered port in t he 33000+ range, such as seen here. This is slight ly different because t he st andard im plem ent at ion of t racerout e uses increm ent ing dest inat ion port s. These are t o st at ic UDP dest inat ion port of 33434. The ant icipat ed response will be a port unreachable error, in which case response t im e can be com put ed when t he 3DNS soft ware receives t he response. The increm ent ing TTL values can also be a signat ure of Tracerout e, if t he DNS server is inside t he sensor t hat capt ured t his act ivit y. 3 D N S t o TCP Por t 5 3 A final at t em pt t o est ablish a connect ion t o TCP port 53 is m ade if all ot hers fail. This at t em pt differs from m ost SYN connect ions because you will see t hat 64 byt es have been included in t he payload. Norm al t raffic has no payload unt il aft er t he t hree- way handshake has been com plet ed. The 64 dat a byt es are sent t o approxim at e a reasonable- sized payload, one t hat is neit her t oo sm all nor t oo large. The ant icipat ed response will be eit her a SYN/ ACK from a list ening server or a RST/ ACK from one t hat is not list ening:

209.67.78.202.2202 > mydns.com.53: S 997788921:997788985(64) win 2048 209.67.78.202.2200 > mydns.com.53: S 869896644:869896708(64) win 2048 209.67.78.202.2201 > mydns.com.53: S 1386586413:1386586477(64) win 2048 216.32.68.11.3102 > mydns.com.53: S 765045139:765045203(64) win 2048 216.32.68.11.3100 > mydns.com.53: S 865977968:865978032(64) win 2048 216.32.68.11.3101 > mydns.com.53: S 565178644:565178708(64) win 2048

This approach seem s dest ined t o fail for m any sit es, especially if t his is t he final at t em pt when all ot hers have failed because of blocked access t o t he ot her

m et hods. The problem is t hat m ost securit y- conscious sit es block access t o TCP dest inat ion port 53 because t hat can be used t o download t he DNS m aps t hat cont ain all regist ered host s and t heir I P num bers. Therefore, if t raffic is blocked, perhaps t hey could do t he m easurem ent s from an I CMP unreachable received from t he rout er blocking t he access. What if t he block was done by a rout er t hat has been silenced from delivering host unreachable errors? This is j ust as fruit less as t he ot her failed at t em pt s.

W or m s a s I n for m a t ion Ga t h e r e r s I f all users at your sit e share a com m on m ail server, and it is configured t o exam ine m ail for viruses t hat have been ident ified, m any m ight be elim inat ed before t hey can infect t he t arget host . But , users m ight not all use t he sam e m ail server; t hey m ight not run virus eradicat ion soft ware; and if t hey do, t hey m ight not updat e it frequent ly. This increases t he risk of infect ion. Viruses and worm s have not been viewed convent ionally as inform at ion gat herers. We are st art ing t o see a new class of worm t hat act s as som e kind of agent t o harvest or seek inform at ion. This m ight involve at t em pt ing connect ions t o ot her host s aft er a host has been infect ed. I f t his is t he case, and t here is som e kind of I DS at an egress point of t he infect ed host , we can observe t he act ivit y. Two such worm s are exam ined here: Pret t y Park and RingZero. Pr e t t y Pa r k W or m I was reviewing an alert about out bound blocked act ivit y at one of our sit es and discovered t hat an int ernal host was at t em pt ing t o connect t o an I nt ernet Relay Chat ( I RC) port 6667 on m any different dest inat ion I Ps. This sit e had blocked out bound act ivit y t o m any of t he convent ionally used I RC port s j ust because t he sit e was hard pressed t o find redeem ing qualit y in m any. I 'm sure it can be argued t hat t here are m any reput able and upst anding chat room s, but oft en t im es users gravit at e t o ones t hat aren't work relat ed. And, every sum m er when t he new crop of cyber- connect ed sum m er st udent s arrived, t his sit e usually saw a couple of t hem t ry t o engage in I RC act ivit y and fail. I t was lat e February, a Friday aft ernoon t o be exact , and I was seeing t his act ivit y. I report ed it t o t he appropriat e cont act , and he said t hat he had inform ed t he owning adm inist rat or of t he det ect ed act ivit y. I also dum ped logs of t he rej ect ed out bound act ivit y, but didn't give t hem m uch scrut iny. Had I been m ore t horough, I would have discovered t hat t he host was at t em pt ing connect ions t o I RC sit es about five t im es a m inut e. This eit her reflect s an obsessive- com pulsive desire t o connect or an aut om at ed program . On t he following Monday, I received anot her alert about out bound I RC act ivit y—no big deal. I j ust t hought it was t he sam e host I had already ident ified t rying once again. But , I searched t he logs again and found four m ore host s engaged in sim ilar

act ivit y. The scary part was t hat t hey were all going t o t he sam e dest inat ion host s, m any of t hem in foreign count ries. And, so t he inevit able t hought of horror arose in m y paranoid analyst 's brain: We had suffered m ult iple com prom ises using a com m on vulnerabilit y, and t he int ruder was t rying t o cont act her hom e base t o report t he t rium ph. Anot her, m ore com fort ing ( com pared t o a com prom ise) t hought occurred t hat m aybe t here was som e kind of worm infect ion. Sure enough, when m y Windows- savvy coworker exam ined one of t he infect ed host s, he locat ed som e st range program s running ( FI LES32.VXD and PRETTY PARK.EXE) and ident ified t his as t he Pret t y Park worm . Using net st at , he discovered t hat t he host had sent a TCP SYN t o dest inat ion port 6667. Apparent ly, Pret t y Park is a worm t hat arrives via an em ail at t achm ent and one of t he dut ies of t he worm is t o go t o t hese I RC sit es in hopes of sending back inform at ion about t he host s—t hings such as passwords and det ails about t he infect ed host . You can get a m ore t horough descript ion of Pret t y Park at ht t p: / / vil.nai.com / vil/ wm 98500.asp. Here is an excerpt of t he act ivit y capt ured by TCPdum p. The dest inat ion port is 6667, and t he dest inat ion host s change:

09:30:34.470000 infected.com.1218 > 662405:662405(0) Âwin 8192 (DF) 09:30:37.370000 infected.com.1218 > 662405:662405(0) Âwin 8192 (DF) 09:30:43.370000 infected.com.1218 > 662405:662405(0) Âwin 8192 (DF) 09:30:55.370000 infected.com.1218 > 662405:662405(0) Âwin 8192 (DF) 09:31:04.050000 infected.com.1220 > 691990:691990(0) Âwin 8192 (DF) 09:31:06.970000 infected.com.1220 > 691990:691990(0) Âwin 8192 (DF) 09:31:12.970000 infected.com.1220 > 691990:691990(0) Âwin 8192 (DF) 09:31:24.970000 infected.com.1220 > 691990:691990(0) Âwin 8192 (DF) 09:32:34.130000 infected.com.1222 > 722101:722101(0) ack 1426589426 win 09:32:43.070000 infected.com.1224 > 782083:782083(0) Âwin 8192 (DF) 09:32:55.070000 infected.com.1224 > 782083:782083(0) Âwin 8192 (DF) 09:33:04.170000 infected.com.1226 > 812112:812112(0) Âwin 8192 (DF)

ircnet.grolier.net.6667: S ircnet.grolier.net.6667: S ircnet.grolier.net.6667: S ircnet.grolier.net.6667: S irc.ncal.verio.net.6667: S irc.ncal.verio.net.6667: S irc.ncal.verio.net.6667: S irc.ncal.verio.net.6667: S mist.cifnet.com.6667: F 8680 (DF) krameria.skybel.net.6667: S krameria.skybel.net.6667: S zafira.eurecom.fr.6667: S

The lesson here is t hat t he t heory of fusing host - based and net work- based soft ware yields t he best result s. On t he host - based side, we would like t o believe t hat worm - eradicat ion soft ware prevent s infect ion, but t his doesn't work for all host s. Det ect ion was net work-

based in t his case because logging t he denied t raffic was what ident ified a possible problem . Rin gZe r o Anot her worm , a Troj an horse known as RingZero, t hat sent out net work t raffic was discovered in Sept em ber 1999. The first ident ified t raffic pat t ern associat ed wit h RingZero was a Shadow det ect of a scan of m any different host s for TCP port 3128, t he squid proxy server port . Here is a sam ple of t he capt ured act ivit y seen by Shadow:

12:29:48.230000 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win 8192 Â (DF) (ttl 19, id 9072) 12:29:58.070000 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win 8192 Â (DF) (ttl 19, id 29552) 12:30:10.960000 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win 8192 Â (DF) (ttl 19, id 39792) 12:44:54.9600001.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win Â8192 (DF) (ttl 242, id 962) 12:44:57.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win Â8192 (DF) (ttl 242, id 11714) 12:45:03.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win Â8192 (DF) (ttl 242, id 22466) 12:45:15.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win Â8192 (DF) (ttl 242, id 33218) 12:46:13.070000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win Â8192 (DF) (ttl 116, id 35676) 12:46:16.080000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win Â8192 (DF) (ttl 116, id 46428) 12:46:22.070000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win Â8192 (DF) (ttl 116, id 57180) 12:46:34.080000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win Â8192 (DF) (ttl 116, id 2397)

Three host ile host s ( 1.1.1.1, 1.2.3.4, and 4.3.2.1) scanned different int ernal 172.16 host s for port 3128. When an addit ional invest igat ion was perform ed, it was discovered t hat t he scanning host also at t em pt ed connect ions t o dest inat ion port s 80 ( HTTP) and 8080 ( alt ernat e HTTP) . Shadow filt ers don't look for t hose dest inat ion port s because t hey are likely t o t rigger a lot of false posit ives. A lot of sit es saw sim ilar act ivit y, and it appeared t o be com ing from m any different source host s from all over t he world wit h as m any as a half dozen different scans per hour. Most of t hese scans hit dest inat ion addresses t hat didn't exist , indicat ing t hat no prior reconnaissance had been done or it hadn't been done well. One t heory concluded t his was from one host t hat was j ust spoofing source I Ps. I n t he preceding scan out put t hat was execut ed wit h t he TCPdum p –vv opt ion, ( t his is t he reason you see t he addit ional inform at ion in parent hesis) , t he TTL value is displayed. The –vv opt ion also displays a field known as t he I P ident ificat ion num ber t hat appears as " id # ." I f t his act ivit y were all from one spoofed source I P, t he arriving TTL value should have rem ained relat ively const ant unless it was

being craft ed. When t racerout es were at t em pt ed back t o m any of t he source I P addresses, t he hop count s t o get from m y sit e back t o t he alleged source I P appeared credible. I f you can est im at e t he init ial TTL assigned by t he source I P and figure out t he difference bet ween t hat and t he arriving TTL, you can approxim at e t he hop count s. The difficult y is guessing t he init ial TTL. I f you look at t he chart found at www.honeynet .org/ papers/ finger/ t races.t xt , m ost t im es you can figure out a reasonable init ial TTL. Not only were t he hop count s believable, but all t he source I Ps appeared t o be alive and pingable, som et hing not t ypically found wit h random ly pirat ed source I Ps. Finally, in t he preceding scan, not ice t hat t he final scanning I P, 1.1.1.1, has different TCP opt ions ( nop, nop, sackOK) from t he ot her records. This point s m ore t o t he source's host s being genuinely different and real, rat her t han a craft er t aking t he t im e t o art ificially int roduce t hese differences. I n conj unct ion wit h a SANS call for help in det erm ining t he cause of t hese scans, a very ast ut e net work adm inist rat or, Ron Marcum of Vanderbilt Universit y, discovered a PC on his net work scanning host s on ot her net works looking for port s 80, 8080, and 3128. The RingZero Troj an appeared t o be t he culprit . I t looked for any host s t hat were using open proxy servers found on port s 3128, 80, or 8080 and, at least for a while, collect ed ones it did find on an FTP sit e. There is value in knowing where an open proxy server is; it enables hackers t o hide t heir t rue source I P ident it ies. Open proxy servers enable you t o t unnel t hrough t hem and assum e t hat I P num ber as t he source I P. Som e quest ions st ill rem ain about RingZero; it is not known how t he Troj an infect s a part icular host , and it has not been det erm ined what I Ps t he Troj an scans when downloaded.

Su m m a r y The at t acker com m unit y is invest ing an incredible am ount of effort t o scan t he I nt ernet . The single m ost im port ant service for your sit e t o block is I CMP echo request s. Reconnaissance probes should be t aken seriously; if at t ackers can learn where your host s are, t hey can m ake fairly short work of det erm ining what services t hese host s run. I f t hey cannot det erm ine which of t he host s in your net work address space are act ive, t hey have a very sparse m at rix wit h which t o work. One great defense is t o use RFC 1918 privat e address space inst ead of using public address space. I f you have public address space and do not have split horizon DNS, at t ackers can j ust ask your DNS server where your host s are wit h reverse lookups. Also, when possible, a NAT is a fant ast ic defense against probing. I recom m end several layers of NATs. Finally, t ry t o configure your perim et er not t o allow I CMP unreachable error m essages out of your net work. Also, wit h t he new class of viruses and worm s being released, infilt rat ion of your well- guarded sit e m ight com e from wit hin. This is a nat ural evolut ion of

inform at ion- gat hering t echniques because m any sit es have becom e m ore proficient at shunning reconnaissance from t he out side.

Abou t t h e Au t h or s St ephen Nort hcut t is a graduat e of Mary Washingt on College. Before ent ering t he field of com put er securit y, he worked as a Navy helicopt er search and rescue crewm an, whit e wat er raft guide, chef, m art ial art s inst ruct or, cart ographer, and net work designer. St ephen is aut hor/ co- aut hor of I ncident Handling St ep by St ep, I nt rusion Signat ures and Analysis, I nside Net work Perim et er Securit y, and t he previous t wo edit ions of t his book. He was t he original aut hor of t he Shadow int rusion det ect ion syst em and leader of t he Depart m ent of Defense's Shadow I nt rusion Det ect ion t eam before accept ing t he posit ion of Chief for I nform at ion Warfare at t he Ballist ic Missile Defense Organizat ion. St ephen current ly serves as Direct or of Training and Cert ificat ion for t he SANS I nst it ut e. Judy Novak is current ly a senior securit y analyst working for t he Balt im ore- based consult ing firm of Jacob and Sundst rom , I nc. She prim arily works at t he Johns Hopkins Universit y Applied Physics Laborat ory where she is involved in int rusion det ect ion and t raffic m onit oring and I nform at ion Operat ions research. Judy was one of t he founding m em bers of t he Arm y Research Labs Com put er I ncident Response Team where she worked for t hree years. She has cont ribut ed t o t he developm ent of a SANS course in TCP/ I P and writ t en a SANS hands- on course, " Net work Traffic Analysis Using t cpdum p," bot h of which are used in SANS cert ificat ions t racks. Judy is a graduat e of t he Universit y of Maryland—hom e of t he 2002 NCAA basket ball cham pions. She is an aging, yet st ill passionat e, bicyclist , and Lance Arm st rong is her m odern- day hero!

Abou t t h e Te ch n ica l Re vie w e r s These reviewers cont ribut ed t heir considerable hands- on expert ise t o t he ent ire developm ent process for Net work I nt rusion Det ect ion, Third Edit ion. As t he book was being writ t en, t hese dedicat ed professionals reviewed all t he m at erial for t echnical cont ent , organizat ion, and flow. Their feedback was crit ical t o ensuring t hat Net work I nt rusion Det ect ion, Third Edit ion fit s our readers' need for t he highest - qualit y t echnical inform at ion. Karen Kent Frederick is a senior securit y engineer for t he Rapid Response t eam at NFR Securit y. She is com plet ing her m ast er's degree in com put er science, focusing in net work securit y, from t he Universit y of I daho's Engineering Out reach program . Karen has over 10 years of experience in t echnical support , syst em adm inist rat ion, and securit y. She holds several cert ificat ions, including t he SANS GSEC, GCI A, GCUX, and GCI H. Karen is one of t he aut hors of I nt rusion Signat ures and Analysis and I nside Net work Perim et er Securit y: The Definit ive Guide t o Firewalls, VPNs, Rout ers, and I nt rusion Det ect ion Syst em s. Karen also frequent ly writ es art icles on int rusion det ect ion for Securit yFocus.com . David Heinbuch j oined t he Johns Hopkins Universit y Applied Physics Laborat ory in 1998. He has experience in int rusion det ect ion, m odeling and sim ulat ion, vulnerabilit y assessm ent , and soft ware developm ent . As a m em ber of t he I nform at ion Operat ions group, he works on program s in various areas, including secure com put ing syst em s, at t ack m odeling and analysis, and int rusion det ect ion. Mr. Heinbuch has a bachelor of science in com put er engineering from Virginia Tech and an m ast er's of science in com put er science from t he Whit ing School of Engineering, Johns Hopkins Universit y.