Arkisto marraskuu, 2009

Viikonlopun Challenge

27 marraskuu 2009

Tässä toinen haaste testata hieman wienie taidot:

Kirjoita tcpdump tai Windump suodatinta, joka tallentaa kaiken liikenteen kanssa lähde IPv6-osoite 2001: DB8:: 10 kautta 2001: DB8:: 20. Melko helppoa, eikö? Jos et ole kokeillut, sinun tulee huomaamaan, että tcpdump / Windump heittää muutaman käyrät sinua.

Voit tarkistaa työtä, tässä on kaapata tiedosto:

ipv6-ICMP

Tiedosto sisältää sekä lähteen IPv6-osoitteita. Ilmeisesti suodattimen pitäisi vain näyttää määritellyn joukon osoitteita.

Voittaja saa innostaa kunnioitusta ja ihailua vähemmän geeks. ;)

Ei kommentteja »

Lähetetty 3-öh , Packet dekoodaus

Tunnisteet:

En tiedä kaikkea, ja se on ok

21 marraskuu 2009

Viime päivinä Juoksin haaste nähdä, kuka voisi kirjoittaa tcpdump / Windump suodatin napata pakettien kanssa Window Scale vaihtoehto asetettu. Se oli hieman aivot solmuun. Se oli yksi niistä ongelmista, joita alkaa ajattelu on helppoa, mutta sitten ymmärtää on erittäin kova. Sitten alkaa kyseenalaistaa jos olet oikealla tiellä, koska se ei voi olla niin monimutkaista kuin miltä se näyttää olevan. Olin nimenomaan yrittää työntää kirjekuoren hieman tässä yksi.

Vuonna haasteeseen totesin, että ihmiset pitäisi lähettää ajatuksiaan / vastauksia kommentit osiossa. Vain yksi henkilö oli halukas tekemään niin, kun kaikki muutkin minuun yhteyttä sähköpostitse. Aluksi luulin sitä yksityisyyttä huolenaihe, mutta sitten muistin että annoin käyttäjät valita minkä tahansa alias he haluavat nimimerkillä. Folks oli joitakin todella hyviä ideoita, mutta mielestäni he pelkäsivät törmännyt liian paljon "newbie" julkisella foorumilla. Olen nähnyt saman asian opetukseen ympäristöissä, joissa opetan topic, kysy jos on kysymyksiä, kukaan nostaa kätensä, mutta loppujen lopuksi olen rivin edessä pöydälleni.

Osuin hieman virstanpylväs tänä vuonna tajusin olen ollut alalla yli 20 vuotta. Voit antaa sinulle käsityksen siitä, kuinka kauan tämä on Internet-aikaa, eräs ensimmäisistä keikoista auttoi muuntamaan hallituksen urakoitsija korvasi "isäntä tiedostojärjestelmä" tähän aivan uuden teknologian nimeltään "Domain Name Services". Muistan kun Gopher liukaskielisistä Syömäkone. Itse kokenut, miten AOL internet-yhteyden dramaattisesti muuttunut maisema tietoturva. Olen työskennellyt niin suuruuksien kuten Robert Morris Sr ja Alan Paller. Olen vaihdettiin kärki ja temppuja tuhansia huipuista kautta SANS Institute. Olen viettänyt aikaa konsultoinnista Valkoisen talon sekä useita muita valtion virastoja.

Ja kaikki, jotka sanoivat, olen ensimmäisenä myöntämässä, että en suinkaan tiedä kaikkea. Itse en täysin tunnista minulla on vielä paljon opittavaa kuin olen jo squirreled pois pikku harmaa soluja. Itse olen vielä törmännyt kamaa (kuten suodatus WScale vaihtoehto), että katson ja sano "Kuinka helvetissä ole huomannut, että kaikki nämä vuodet?".

Yksi asia pakkomielteinen puolella minua rakastaa noin tietoturvan on, että se on pohjaton kaivo. Voit viettää joka herää hetki lukemalla blog / list viestiä, lataaminen työkalut, testaus laboratoriossa, ja silti ei voi kietoa aivosi ympärille kaikki. Verkon turvallisuus on hienovarainen ja täynnä vivahteita. Jokaisen aivot on kytketty eri tavalla, joten osa näistä vivahteita ovat ilmeiset, ja toiset ei niinkään. Yksi jäähtyä asioita kiinni itse siellä on sinulle hyötyä muiden ihmisten aivojen kemiaa. Selkeästi yksi suurimmista ongelmista on valkoinen hattu puolella aitaa on, että emme vaihtaa ajatuksia / näkökulmia riittävän usein. Mielestäni aivan liian usein ego estää meitä.

Onko ihmiset, jotka kuvittelevat tietävänsä kaiken? Ehdottomasti. Jälleen ego voi olla hankala isäntä. Olen mieleen ne vanhat t-paitoja ja julisteita, joissa lukee: "Nuoria: Jätä kotiin kun vielä tiedä kaikkea!". Kanssa verkon turvallisuuden, kuten useimmat asiat elämässä, on esteenä valaistumisen. Toisella puolella este, lampi tuntuu pieni ja olet mielestäsi kahva kaiken. Kun murtaa kuitenkin tunnistat valtaville galaksia ja kuinka pitkälle eteenpäin, että tie vielä venyy.

Joten olen ehdottanut 12 askeleen Geek ohjelma ja otan ensimmäisenä kiivetä juhlapuheissa ja myöntävät "en tiedä kaikkea ja olen OK kanssa". Osasyynä annoin Jeff Toiseksi hän tuli ongelma täysin erilaisesta lähestymistavasta ja kehitetty ratkaisu en ajattele. Toisin sanoen laittamalla itseni siellä sain hyötyä hänen aivojen kemiaa.

Kuten Jeff, jokainen lukee tätä piirtää oman ainutlaatuisen elämänkokemuksen ja ovat täysin kykeneviä keksimään ainutlaatuisia ja innovatiivisia ratkaisuja samoin. Et koskaan tiedä varmasti, mutta ellet tarkistaa ego Gremlin ja kiinni itse siellä.

</ Juhlapuheissa>

Chris

4 kommenttia »

Posted in 1-kehittyvillä , General IT

Tunnisteet:

Voi missä, oi missä voi WScale olla?

20 marraskuu 2009

Jos tämä haaste tuntui vaikeampaa kuin se on, olet oikeilla jäljillä. ;)

Minä juoksin koko tämän ongelman, kun kirjoittaessani Packet Decode työkalu. Minun täytyy sanoa, se oli viileä harjoitus minulle, koska en ole koskaan oikeastaan ​​ajatellut luoda tcpdump ja Wireshark suodattimet kaikkiin mahdollisiin IP, TCP, UDP ja ICMP alalla ja / tai arvo. Ylivoimaisesti TCP Kenttä on kaikkein "rikki" mistä paketti purkaa näkökulmasta kuin muut IP-kenttään.

Ensimmäinen Puhutaanpa miten TCP vaihtoehtoja olisi pitänyt panna täytäntöön. Jos katsot IPv4 vaihtoehtoja kentän, se alkaa "Type" tunniste. Jos olet kiinnostunut tietyn IP-vaihtoehto, se on vain asia tarkistaa tämän alan oikeutta bittinen yhdistelmä. Oli TCP vaihtoehtoja on toteutettu tällä tavalla, tähän haasteeseen olisi ollut melko yksinkertaista.

Lähes kaikki TCP vaihtoehtoja on "laji" ja "Pituus" kentässä, jotka molemmat ovat 1 tavu kooltaan. Poikkeuksia ovat "End of Option List" ja "Ei-operaatio", joka vain on eräänlainen toimintaedellytykset ja ovat yhden tavun kokoisia. Tässä lista yhteistä TCP vaihtoehdoista:

tcp-options

Sivu 15 RFC 793 kertoo meille "TCP header (yksikin optiot mukaan lukien) on olennainen määrä 32 bittiä pitkä." Toisin sanoen, TCP-otsikon koko tavuina on jaollinen neljällä (20 tavua, 24 tavua, jne.). Jos tarkastellaan luetteloa TCP vaihtoehtoja, vain "segmentin enimmäiskoko" on jaollinen neljällä. Joten käyttää mitään muita vaihtoehtoja, on tehtävä täyte.

Miten pehmuste olisi sovellettava on vähän epäselvä. Jos katsomme sivu 26 RFC 1323 löydämme tähän: 

 LIITE: TOTEUTUS EHDOTUKSET Seuraavat asettelujen suositellaan lähetysvalintoja Ei-SYN segmentit, maksimaalisen mahdollista yhdenmukaistamista 32-bittinen ja 64-bittisillä koneilla.  +--------+--------+--------+--------+ | NOP ​​| NOP ​​| TSopt | 10 | + --- -----+--------+--------+--------+ | TSval timestamp | +--------+--- -----+--------+--------+ | TSecr timestamp | +--------+--------+--- -----+--------+

Huom NOP täyte näkyy ennen timestamp vaihtoehto, ei lopussa kuten arvata saattaa. Huomaa myös RFC nimenomaan sanoo että tämä on "ei-SYN segmentit" ja että se on "suositeltu", ei tarvita. Näyttää kuitenkin siltä, ​​että useimmat käyttöjärjestelmät noudattaa suositusta ja aina paikka pehmuste ennen Kind ja pituus tavua. Olen tarkistanut Windows, Linux, Mac, eri laitteisto, jne. ja ne kaikki laittaa pehmusteet alussa.

Joten voimme luottaa että tämä on "standardi", eikö? Ei aivan. Sivu 17 RFC 793 kuvaa NOP näin: 

  Tämä vaihtoehto koodia voidaan käyttää eri vaihtoehtojen välillä, esimerkiksi
         Kohdista alusta myöhemmän vaihtoehdon sanan rajan.
         Ei ole mitään takeita siitä, että lähettäjä käyttää tätä vaihtoehtoa, joten
         vastaanottimia on oltava valmis käsittelemään vaihtoehtoja, vaikka ne eivät
         ei alkaa sanan rajan.

Toisin sanoen, se ei ole vain siitä, että NOP välttämättä näy alussa, NOP ei välttämättä käytetä lainkaan! On täysin laillista layout TCP Option Field ilman NOP pehmusteet ja vain käyttää loppu Asetusluettelo täyteaineena lopussa saavutettaisiin asianmukainen raja.

Mitä me lopulta varten suodattimen? Jos me luottaa NOP ennen optio päädymme suodatin näyttää tältä:

tcp [13] & 2 = 2 ja tcp [12] ja 240> 80 ja ((tcp [20] = 1 ja tcp [21:2] = 0 × 0303) tai (TCP [24] = 1 ja tcp [25:2 ] = 0 × 0303) tai (TCP [28] = 1 ja tcp [29:2] = 0 × 0303) tai (TCP [32] = 1 ja tcp [33:2] = 0 × 0303) tai (tcp [ 36] = 1 ja tcp [37:2] = 0 × 0303) tai (TCP [40] = 1 ja tcp [41:2] = 0 × 0303) tai (TCP [44] = 1 ja tcp [45:2 ] = 0 × 0303) tai (TCP [48] = 1 ja tcp [49:2] = 0 × 0303) tai (TCP [52] = 1 ja tcp [53:2] = 0 × 0303) tai (tcp [ 56] = 1 ja tcp [57:2] = 0 × 0303))

Murtamaan mitä tämä suodatin on tekemässä:

  • Vain Tarkista SYN & SYN / ACK-paketteja: tcp [13] & 2 = 2
  • TCP header on suurempi kuin 20 tavua (asetukset ovat): TCP [12] ja 240> 80
  • Tarkista ensimmäinen tavu kunkin neljän tavun rajalla on NOP: tcp [20] = 1, tcp [24 = 1, ...
  • Tarkista seuraavat kaksi tavua, onko Kind = 3 ja pituus = 3: TCP [21:2] = 0 × 0303, tcp [25:2] = 0 × 0303, ...

Jos kuitenkin haluamme varmistaa, että me kiinni kaikki mahdollisuudet asiassa järjestelmä ei toteuta NOP päädymme:

tcp [13] & 2 = 2 ja tcp [12] ja 240> 80 ja (tcp [20:2] = 0 × 0303 tai tcp [21:2] = 0 × 0303 tai tcp [22:2] = 0 × 0303 tai tcp [23:2] = 0 × 0303 tai tcp [24:2] = 0 × 0303 tai tcp [25:2] = 0 × 0303 tai tcp [26:2] = 0 × 0303 tai tcp [27:2] = 0 × 0303 tai tcp [28:2] = 0 × 0303 tai tcp [29:2] = 0 × 0303 tai tcp [30:2] = 0 × 0303 tai tcp [31:2] = 0 × 0303 tai tcp [32:2] = 0 × 0303 tai tcp [33:2] = 0 × 0303 tai tcp [34:2] = 0 × 0303 tai tcp [35:2] = 0 × 0303 tai tcp [36:2] = 0 × 0303 tai tcp [37:2] = 0 × 0303 tai tcp [38:2] = 0 × 0303 tai tcp [39:2] = 0 × 0303 tai tcp [40:2] = 0 × 0303 tai tcp [ 41:2] = 0 × 0303 tai tcp [42:2] = 0 × 0303 tai tcp [43:2] = 0 × 0303 tai tcp [44:2] = 0 × 0303 tai tcp [45:2] = 0 × 0303 tai tcp [46:2] = 0 × 0303 tai tcp [47:2] = 0 × 0303 tai tcp [48:2] = 0 × 0303 tai tcp [49:2] = 0 × 0303 tai tcp [50 : 2] = 0 × 0303 tai tcp [51:2] = 0 × 0303 tai tcp [52:2] = 0 × 0303 tai tcp [53:2] = 0 × 0303 tai tcp [54:2] = 0 × 0303 tai tcp [55:2] = 0 × 0303 tai tcp [56:2] = 0 × 0303 tai tcp [57:2] = 0 × 0303 tai tcp [58:2] = 0 × 0303)

Ero Kun suodatin on, että olemme tarkistaa Kind = 3 ja pituus = 3 kaikki läpi vaihtoehtoja kentän (kuten Elizabeth ehdotti).

Voi jompikumpi näistä suodattimet aiheuttaa vääriä positiivisia? Ehdottomasti! Kaksi mahdollisuutta:

  1. Arvo aikaleima voi vastaisivat mallia etsimme.
  2. Suodatin olettaa 40 tavun vaihtoehto kenttään. Se voisi olla vähemmän näitä arvoja hyötykuorma.

Joten mikä suodatin tulisi käyttää? Ensimmäinen tuottaa vähemmän vääriä positiivisia, mutta miss järjestelmiä, jotka ovat RFC-yhteensopiva, mutta eroaa normi. Toinen on aina kiinni Window mittakaavassa, jos se on asetettu, mutta mahdollisuus vääriä positiivisia on korkeampi.

Aion nimetä Elizabeth kuin voittaja haaste. Muutamat muut olivat yhtä lähellä, mutta hän oli ainoa, jolla on kanttia lähettää hänelle ajatusketju kommenteissa. Aion tehdä toisen palkinnon Jeff kuka keksi tähän ratkaisuun osittain vitsi ympärillä:

tcpdump-nn | grep 'wscale "> wscale-matches.txt

Tämä ei synny todellista packet capture, mutta voit tehdä:

tcpdump-nn-X-s 0 | grep 'wscale "> wscale-matches.txt

Ja sitten ajaa ääntä txt2cap saada se takaisin pcap muotoon. Hän ei noudata haaste erityisesti, mutta sinun pitää antaa Kudos ajatella ulkopuolella ruutuun, koska se korjaa kaikki vääriä positiivisia asioita. ;)

Elizabeth ja Jeff, otan sinuun yhteyttä niin sähköpostitse. Onnea!

Ei kommentteja »

Lähetetty 3-öh , Packet dekoodaus

Tunnisteet:

TCP Options - Lopullinen vihje

19 marraskuu 2009

Minulla oli yksi kierre viesti ja neljä sähköpostiviestejä, jotka ovat soooooo lähellä oikeaa vastausta. Tässä yksi viime vihjeen toivottavasti saamme ihmiset yli viimeisen esteensä.

Mainitsin avulias tshark komento. Tässä lähtö:

C: \ testaus> tshark-n-R linux-syn.cap-T kentät-e tcp.options
02:04:05: B4: 04:02:08:0: 02:47:04: A8: 00:00:00:00:01:03:03:05

Joten mitä olet edellä on TCP-osio (tavu 20 ja uudemmat) testin paketin. Window Scale vaihtoehto on viimeinen vaihtoehto luettelosta.

Tiedän kirjallisesti tätä suodatinta ei ole helppoa. Itse asiassa siksi minä muutti sen haaste. On mahdollista kuitenkin. ;)

1 kommentti »

Lähetetty 3-öh , Packet dekoodaus

Tunnisteet:

TCP Options Challenge - vihjeitä

18 marraskuu 2009

Aikaisemmin olen lähettänyt haasteen kirjoittaa tcpdump / Windump suodatin, joka kaapata paketteja, jotka ovat TCP vaihtoehto "Ikkuna Scale" set. Jotkut ihmiset ovat lähellä, mutta halusin lähettää joitakin vihjeitä. Lisäksi minulla ei ole ongelma sinulle sähköpostitse minulle suoraan, mutta voittaa haasteen sinun täytyy lähettää vastaus kommentit osiossa. Näin ei ole kysymys siitä, kuka löytänyt vastausta ensin.

Kaikki TCP vaihtoehdot ovat määritelty "Registry Kind" arvo (samanlainen ICMP "Type"-kenttään). Kun kyseessä Window Scale, että arvo on 3. Myös kaikki TCP vaihtoehtoja paitsi NOP sisältävät toisen kentän nimeltä "Pituus". Tämä määrittää kuinka monta tavua vaihtoehtoja käyttää myös "Registry Kind" tavu. Kun kyseessä ikkuna Scale pituus arvo on aina 3. Joten meillä on:

  • 1 tavu Rekisterin Kind
  • 1 tavun pituus
  • 1 tavu varsinaiseen WScale arvo

Vihje 2: Jos et ole koskaan porattu TCP asetusten kenttä tshark on viileä vaihtoehto:

tshark-n-r capture-file.cap-T kentät-e tcp.options

Tämä lähtö koko TCP vaihtoehtoja kentän Hex joten voit ainakin nähdä miltä se näyttää.

Lopullinen vihje, olen lähettänyt Linux SYN paketin jossa WScale 5 voit käyttää tarkistaaksesi suodattimen.

linux-SYN

Onnea!

Chris

Ei kommentteja »

Lähetetty 2-hälytys , Packet dekoodaus

Tunnisteet:

TCP Options Challenge

18 marraskuu 2009

Minulla on ollut hieman meneillään lukien vapauttamista uusi viittaus työkalu Apple iPhone ja iPod. Työkalu on puhelu Packet Decode ja olen setup vaihtoehtoinen sivusto auttaa ylläpitämään sitä.

Tunnen huono laiminlyö tämän sivuston viime viikkoina, niin olen päättänyt heittää ulos toinen haaste. Voittaja saa ilmaisen kopion edellä mainituista Packet Decode työkalu. OK, joten et voi jäädä etenee, mutta toivottavasti työkalu tekee elämästäsi hieman helpompaa. ;)

Joten tässä on haaste:

Kirjoita tcpdump tai Windump suodatinta, joka vain kaapata paketit, joiden TCP "Ikkuna Scale" vaihtoehto asetettu. Kaikki muut TCP vaihtoehto asetukset voidaan jättää huomiotta.

Melko yksinkertainen, vai? Ensimmäinen henkilö lähettää vastauksen kommentit osassa saa palkinnon.

2 kommenttia »

Lähetetty 2-hälytys , Packet dekoodaus

Tunnisteet: