Fire w alk ing - w h at / w h y / h ow by M arco Ge rbe r. Mit was beschäftigt sich firewalking

Transkript

1 Fire w alk ing - w h at / w h y / h ow by M arco Ge rbe r M it w as b e sch äftigt sich fire w alk ing Pak e taufbau Tools W as m an dage ge n tun k ann Mit was beschäftigt sich firewalking Beim firewalking geht es darum, mittels gezielten Netzwerkpaketen einen Pfad durch eine Firewall zu finden. Dabei bedient man sich bekannten und unbekannten Fehlkonfigurationen auf Rules / ACLs. Zie lpublik um : Es ist von Vorte il, w e nn de r Le se r be re its Ke nntnisse im Be re ich de r Ne tzw e rk te ch nik m itbringt. Er so lte dabe i de n grundsätzlich e n Sach ve rh alt de r Protok o le / Laye r ve rste h e n. Für das nach vo lzie h e n de r Be ispie le w ird e in Linux/UNIX Syste m e m pfoh le n. Zue rst e inm alm uss m an sich be w usst se in, dass e in Syste m im m e r nur so sich e r ist, w ie e in Angre ife r dum m. Und ge nau de m lie gt das Proble m de r Sich e rh e it von Fire w a lsyste m e n zu Grunde. Grundsätzlich ist e in grosse s M issve rständnis im Um lauf, w e lch e s darauf be ruh t, e in Syste m dadurch abzusich e rn, inde m ICM P ECH O REQUEST Pak e te abge fange n w e rde n, um so die Existe nz e ine s Re ch ne rs zu ve rbe rge n. Vie le Program m e, w e lch e sich zum fläch e nde ck e nde n Scanne n von Ne tzw e rk e n e igne n, e rm itte ln das Vorh ande nse in e ine s Re ch ne rs durch das Se nde n e ine s solch e n "ping"pak e te s. Dabe i e ntsch e ide n die se aufgrund de r e rh alte ne n Antw ort, ob e in Re ch ne r e xistie rt ode r nich t. Abge se h e n davon, dass e s sow ie so de r Eth ik w ide rsprich t, be nutze n solch e Program m e für die se Art de s Ne tzw e rk scannings sow ie so m e ist nur soge nannte Sk ript Kiddie s. Sie ste le n in de r Re ge lk e ine grosse Ge fah r dar. Be im fire w alk ing ge h t e s abe r um e ine ande re Art de s h ack e ns (zur Be griffse rläute rung sie h e h ttp://w w w.catb.org/~ e sr/faqs/h ack e r-h ow to.h tm l). Es ge h t darum, ge zie lt durch die Ke nntnis de r Existe nz e ine s Re ch ne rs die Fire w a lk onfiguration zu die se m Syste m zu te ste n.

2 Für unse re Zw e ck e h ie r baue n w ir e in virtue le s Ne tzw e rk w ie in de r ne be nste h e nde n Abbildung auf. Es die nt de n grundsätzlich e n Übe rle gunge n für die nach - folge nde n Erläute runge n. [Zie l-ne tz ] : Re ch ne r : Zie l-re ch ne r : Re ch ne r : Route r + Fire w a l [Qu e l-ne tz ] : Route r : Re ch ne r, von w e lch e m aus de r Te st e rfolgt Unse re Vorausse tzunge n zum fire w alk ing sind nun die folge nde n: W ir w isse n übe r die Existe nz de s Zie lre ch ne r be sch e id. Das Zie list folge nde s: Gibt e s e ine n Fe h le r in de r Fire w a lk onfiguration zum Zugang zum Zie lre ch ne r, w e lch e sich für Date ntransfe r e igne t? Für Date ntransfe r e igne n sich Protok o le, w e lch e auf IP aufse tze n (TCP/UDP usw ) Eine trace route Ausgabe von zum Zie lre ch ne r w ird dann in e tw a w ie folgt ausse h e n: [th e ore tisch e Ausgabe ] m s 2.600m s 2.670m s m s 3.000m s 3.120m s [re ale Ausgabe ] 2 * * * 3 * * * Re ale Ausgabe be de ute t, dass die Fire w a lunse re Trace pak e te abge fange n h at, und nach e ine m Tim e out Trace route e ntsch e ide t, dass das Zie lnich t anspre ch bar ist.

3 W ir w isse n, dass Trace route standardm ässig so arbe ite t, dass nach je de m ge se nde te n Pak e t de r Zie lport (UDP) um 1 ink re m e ntie rt w ird. De r Startport ist auf fe stge le gt. Er lässt sich anpasse n. Die Route zum Zie list uns noch nich t be k annt. Pak e taufbau: Es ge h t nun darum, e ine n Port zu finde n, w e lch e r für e ine Date nübe rtragung von de r Fire w a lzuge lasse n ist. H ie r bie te n sich nun die M öglich k e ite n, die Startports se lbst zu w äh le n. De r TTLW e rt im IP H e ade r k ann ge nau an die abzufrage nde Num m e r ge se tzt w e rde n. Je doch w ird zunäch st m it ICM P ve rsuch t, die Route k om ple tt aufzuze ich ne n. Die s lie fe rt uns w e rtvo le Inform atione n darübe r, w ie w e it e s bis zum Zie lnoch ist. W ir w e ise n also Trace route an, ICM P ECH O REQUEST Pak e te zu se nde n. Ge nau gle ich w ie zuvor, w e rde n die Route r zum Zie lfortlaufe nd de n TTL0 W e rt m it e ine m TIM E EXCEEDED IN-TRANSIT anze ige n. De r Vorte ilbe i die se r M e th ode lie gt darin, dass w ir e ine n ECH O REQUEST se nde n, w e lch e r von de n m e iste n Route rn im Ge ge nsatz zu e ine m UDP Pak e t passie rbar ist. trace route -I lie fe rt dann: m s 2.600m s 2.670m s m s 3.000m s 3.120m s Nun k e nne n w ir de n Route r, w e lch e r die UDP Pak e te ge block t h at. Auf die se m w ird e ine Re ge lse in, w e lch e UDP Traffic auf de m ge w äh lte n Port unte rbinde t. Ab h ie r w isse n w ir folge nde s: De r Route r be sitzt e ine Fire w a lre ge l(w obe i Fire w a lh ie r bre it ge fasst ist) H inte r de m Route r be finde t sich im gle ich e n Subne t unse r Zie lre ch ne r. W as w ir abe r noch nich t w isse n ist: Ist de r antw orte nde Re ch ne r auch de r, für w e lch e n w ir ih n h alte n Um w as für e ine Art Ne tzw e rk h ande lt e s sich, in w e lch e m sich unse r Zie lre ch ne r be finde t.

4 Kann m an nun in Erfah rung brige n, um w as für e ine Art Ne tzw e rk e s sich h ande lt, k ann m an die m it grosse r Sich e rh e it zuge lasse ne n Die nste stark e ingre nze n. Auch h ie r h ilft uns ICM P w e ite r. Näm lich m it de m Code 17 (ADDRESS_M ASK_REQUEST). Die se r Code w e ist e ine n Route r an, die Subne tm ask se ine s Ne tzw e rk e s zurück zu ge be n. H ie rzu k ann m an sich de m Toolh ping be die ne n, w e lch e s die M öglich k e it zum ge zie lte n Erste le n e ine s Pak e te s lie fe rt: h ping icm ptype 17 -c 1 2> & 1 gre p "m ask "(und ode r ) -> ICM P addre ss m ask : icm pam = Es m uss sich also um e in se h r grosse s Ne tzw e rk h ande ln, w e lch e s im Privatbe re ich be nutzt w ird (w isse n w ir e ige ntlich sch on lange, abe r ich ve rw e nde h ie rfür be w usst private Ne tzw e rk e - Anm. e s h ande lt sich um das Ne tzw e rk auf Se ite n de s Aufrufe rs). So ist die W ah rsch e inlich k e it also se h r gross, dass sich e r DNS zuge lasse n ist. Ebe nfa ls ve rm utlich noch e in syslogd, w e lch e r von ausse n h e r ange sproch e n w e rde n k ann. Se rve r w e rde n be w usst k e ine be trach te t, da die se für unse re Be lange n nich t von Inte re sse sind. Ebe nfa ls ist die Um ge bung von Se rve rn m e ist gründlich e r abge sich e rt als de r Re st. M it de n ge w onne ne n Date n lässt sich nun e in zw e ite r Anlauf m it trace route starte n, w e lch e r die se Erk e nntnisse nutzt. trace route p 53 -f 2 -n m s * * Dam it h abe n w ir e ine n W e g ge funde n, w e lch e r für e ine n Date naustausch brauch bar ist. Einge se tzte Tools: Im Grunde re ich e n e in paar w e nige Tools, w e lch e uns Ne tzw e rk pak e te ge ne rie re n. Ein dafür ge e igne te s finde t m an unte r de m Nam e n "h ping". h ping trace rou te norm ale UNIX Tools

5 W as m an dage ge n tun k ann: Grundsätzlich e ine Einsch ränk ung de s Zugriffe s durch die obe n be sch rie be ne n M öglich k e ite n, in de m m an h auptsäch lich de n UDP und ICM P Ve rk e h r ge zie lte r re ge lt. Die s w ird oft ve rnach lässigt, w e iludp nich t so se h r ve rbre ite t ist in de n be k annte re n Angriffsve rfah re n auf de n Ne tzw e rk stack und Ne tzw e rk e im a lge m e ine n. Ein ICM P_NETW O RK_UNREACH ABLE (M e ssage type 2 Code 11) k ann das Scanne n m it de n ge ze igte n ICM P Pak e te n e insch ränk e n. Auf Linux Syste m e n e igne t sich iptable s als Fronte nd für ne tfilte r zur Konfiguration ge e igne te r Rule s: iptables -A INPUT -i <DEVICE> -d <NETWORK> -p icmp --icmp-type \ address-mask-request -j REJECT --reject-with icmp-net-unreachable iptables -A INPUT -i <DEVICE> -d <NETWORK> -p icmp --icmp-type \ echo-request -j REJECT --reject-with icmp-net-unreachable Au tor: M arco Ge rbe r ist Stude nt de r Inform atik und be sch äftigt sich se it nun m e h r als 6 Jah re n m it Linux/UNIX und Com pute rsich e rh e it. h ttp://sque e z.gurit.ne t