Hvis denne utfordringen virket vanskeligere enn det burde være, er du på rett spor. 
Jeg kjørte over dette problemet ved å skrive min Packet Dekode verktøyet. Jeg må si, det var en kul øvelse for meg, som jeg egentlig aldri tenkt på å lage tcpdump og wireshark filtre for alle mulige IP, TCP, UDP og ICMP felt og / eller verdi. Den klart TCP alternativene feltet er det mest "brutt" fra en pakke dekode perspektiv enn noen annen IP-feltet.
Først la oss snakke om hvordan TCP alternativene burde vært gjennomført. Hvis du ser på IPv4 alternativene feltet, begynner det med en "Type" identifikator. Hvis du er interessert i en bestemt IP-alternativet, er det bare et spørsmål om å sjekke dette feltet for retten bit kombinasjonen. Hadde TCP alternativene er gjennomført på denne måten, ville denne utfordringen har vært ganske rett frem.
Omtrent alle TCP alternativer har en "Kind" og en "Length" feltet, som begge er en byte i størrelse. Unntakene er "End of Option List" og "No-Operation" som bare har en slags felt, og dermed er en byte i størrelse. Her er en liste over vanlige TCP alternativer:
Side 15 av RFC 793 forteller oss "The TCP header (selv en inkludert opsjoner) er en integrert antall 32 bits lang." Med andre ord må TCP header størrelsen i byte være delelig med fire (20 byte, 24 bytes, etc.). Hvis du ser på listen av TCP alternativer, bare "Maximum Segment Size" er delelig med fire. Så bruk av noen andre alternativer kommer til å kreve padding.
Hvordan padding bør påføres er litt uklart. Hvis vi ser på side 26 av RFC 1323 finner vi dette:
VEDLEGG A: GJENNOMFØRING FORSLAG
Følgende oppsett er anbefalt for sendingsvalg på ikke-SYN
segmenter, for å oppnå maksimal mulig justering av 32-bit og 64-bit
maskiner.
+--------+--------+--------+--------+
| NOP | NOP | TSopt | 10 |
+--------+--------+--------+--------+
| TSval timestamp |
+--------+--------+--------+--------+
| TSecr timestamp |
+--------+--------+--------+--------+ Legg merke til NOP padding vises før timestamp alternativet, ikke på slutten som du kanskje forventer. Også merke til RFC sier spesifikt dette er for "non-SYN segmenter", og at det er "anbefalt", ikke påkrevet. Synes imidlertid at de fleste operativsystemer følger denne anbefalingen og alltid plass padding før Kind og Lengde bytes. Jeg har sjekket Windows, Linux, Mac, diverse hardware, osv., og de alle sette padding i begynnelsen.
Så vi kan regne med at dette er den "standard", ikke sant? Ikke helt. Side 17 av RFC 793 beskriver NOP på denne måten:
Dette alternativet koden kan brukes mellom alternativer, for eksempel til
justere begynnelsen av påfølgende opsjon på et ord grense.
Det er ingen garanti for at avsenderne vil bruke dette alternativet, så
mottakere må være forberedt på å behandle alternativer selv om de gjør
ikke begynne på et ord grense. Med andre ord, det er ikke bare at NOP kan eller ikke kan vise opp på begynnelsen kan NOP ikke bli brukt i det hele tatt! Det er helt lovlig å layout TCP alternativet feltet med ingen NOP polstring og bare bruke End of Option List som fyllstoff på slutten for å oppnå riktig grense.
Så hva ender vi opp med et filter? Hvis vi regner på NOP før valget vi ender opp med et filter som ser slik ut:
tcp [13] og 2 = 2 og tcp [12] og 240> 80 og ((tcp [20] = 1 og tcp [21:02] = 0 × 0303) eller (tcp [24] = 1 og tcp [25:2 ] = 0 × 0303) eller (tcp [28] = 1 og tcp [29:2] = 0 × 0303) eller (tcp [32] = 1 og tcp [33:2] = 0 × 0303) eller (tcp [ 36] = 1 og tcp [37:2] = 0 × 0303) eller (tcp [40] = 1 og tcp [41:2] = 0 × 0303) eller (tcp [44] = 1 og tcp [45:2 ] = 0 × 0303) eller (tcp [48] = 1 og tcp [49:2] = 0 × 0303) eller (tcp [52] = 1 og tcp [53:2] = 0 × 0303) eller (tcp [ 56] = 1 og tcp [57:2] = 0 × 0303))
Å bryte ned hva dette filteret gjør:
- Bare sjekke SYN & SYN / ACK pakker: tcp [13] og 2 = 2
- TCP header er større enn 20 bytes (alternativer er satt): tcp [12] og 240> 80
- Kontroller den første byte i hver fire byte grense for NOP: tcp [20] = 1, tcp [24 = 1, ...
- Sjekk de to neste byte for å se om Kind = 3 og Lengde = 3: tcp [21:02] = 0 × 0303 TCP [25:2] = 0 × 0303 ...
Hvis derimot vi ønsker å sikre at vi fange alle muligheter i tilfelle et system som ikke gjennomfører NOP vi ender opp med:
tcp [13] og 2 = 2 og tcp [12] og 240> 80 og (tcp [20:02] = 0 × 0303 eller tcp [21:02] = 0 × 0303 eller tcp [22:02] = 0 × 0303 eller tcp [23:02] = 0 × 0303 eller tcp [24:2] = 0 × 0303 eller tcp [25:2] = 0 × 0303 eller tcp [26:2] = 0 × 0303 eller tcp [27:2] = 0 × 0303 eller tcp [28:2] = 0 × 0303 eller tcp [29:2] = 0 × 0303 eller tcp [30:2] = 0 × 0303 eller tcp [31:2] = 0 × 0303 eller tcp [32:2] = 0 × 0303 eller tcp [33:2] = 0 × 0303 eller tcp [34:2] = 0 × 0303 eller tcp [35:2] = 0 × 0303 eller tcp [36:2] = 0 × 0303 eller tcp [37:2] = 0 × 0303 eller tcp [38:2] = 0 × 0303 eller tcp [39:2] = 0 × 0303 eller tcp [40:2] = 0 × 0303 eller tcp [ 41:2] = 0 × 0303 eller tcp [42:2] = 0 × 0303 eller tcp [43:2] = 0 × 0303 eller tcp [44:2] = 0 × 0303 eller tcp [45:2] = 0 × 0303 eller tcp [46:2] = 0 × 0303 eller tcp [47:2] = 0 × 0303 eller tcp [48:2] = 0 × 0303 eller tcp [49:2] = 0 × 0303 eller tcp [50 : 2] = 0 × 0303 eller tcp [51:2] = 0 × 0303 eller tcp [52:2] = 0 × 0303 eller tcp [53:2] = 0 × 0303 eller tcp [54:2] = 0 × 0303 eller tcp [55:2] = 0 × 0303 eller tcp [56:2] = 0 × 0303 eller tcp [57:2] = 0 × 0303 eller tcp [58:2] = 0 × 0303)
Forskjellen med dette filteret er at vi sjekker Kind = 3 og Lengde = 3 hele veien gjennom alternativene feltet (som Elizabeth foreslått).
Kan noen av disse filtrene generere falske positiver? Absolutt! To muligheter:
- Verdien av Tidsstempel kan matche det mønsteret vi leter etter.
- Filteret forutsetter en 40 byte alternativ feltet. Det kan være mindre med disse verdiene i nyttelasten.
Så hvilke filter bør du bruke? Den første vil generere færre falske positiver, men savner systemer som er RFC-kompatibel, men forskjellig fra normen. Det andre vil alltid fange Vindu Scale om det har blitt satt, men sjansen for en falsk positiv er høyere.
Jeg kommer til å utpeke Elizabeth som vinner av utfordringen. Et par andre ble like tett, men hun var den eneste med guts til å legge sin tankerekke i kommentarfeltet. Jeg kommer til å utdele en andrepris til Jeff som kom opp med denne løsningen delvis tuller rundt:
tcpdump-nn | grep 'wscale'> wscale-matches.txt
Dette vil ikke generere en faktisk pakke fange, men du kunne gjøre en:
tcpdump-nn-X-s 0 | grep 'wscale'> wscale-matches.txt
Og deretter kjøre ut gjennom txt2cap å få det tilbake i pcap format. Han fulgte ikke utfordringen spesifikt, men du har må gi kudos for å tenke utenfor boksen da dette fikser alle falske positive saker.
Elizabeth og Jeff, vil jeg kontakte deg både via e-post. Gratulerer!
