Om den här utmaningen verkade svårare än det borde vara, är du på rätt väg. 
Jag sprang över det här problemet när du skriver min Packet Decode verktyg. Jag måste säga, det var en cool övning för mig, eftersom jag aldrig riktigt tänkt på att skapa tcpdump och Wireshark filter för alla möjliga IP, TCP, UDP och ICMP område och / eller värde. Den överlägset TCP optioner fältet är den mest "trasiga" från ett paket avkoda perspektiv än någon annan IP-området.
Först ska vi prata om hur TCP optioner skulle ha varit genomfört. Om du tittar på IPv4 alternativ fältet, börjar det med en "Typ" identifierare. Om du är intresserad av en specifik IP-alternativ, det är bara en fråga om att kontrollera detta fält för rätt lite kombination. Hade TCP optioner genomförts på detta sätt skulle den här utmaningen har varit ganska rakt framåt.
Bara om alla TCP Optionerna har en "snäll" och "Längd"-fältet, som båda är 1 byte i storlek. Undantagen är "End of Option List" och "No-Operation" som bara har en sort konkurrensvillkor, och därmed är en byte i storlek. Här är en lista över vanliga TCP optioner:
Sidan 15 av RFC 793 berättar för oss "TCP-huvudet (även ett inklusive optioner) är ett helt antal 32 bitar långa." Med andra ord måste TCP-huvudet storlek i byte vara jämnt delbart med fyra (20 byte, 24 byte, etc.). Om man tittar på listan över TCP optioner, bara "Maximum Segment Size" är delbart med fyra. Så användning av andra alternativ kommer att kräva stoppning.
Hur stoppning bör tillämpas är lite oklart. Om vi tittar på sidan 26 i RFC 1323 finner vi detta:
BILAGA A: GENOMFÖRANDE FÖRSLAG
Följande layouter rekommenderas för sändningsalternativ på icke-SYN
segment, för att uppnå högsta möjliga anpassning av 32-bitars och 64-bitars
maskiner.
+--------+--------+--------+--------+
| NOP | NOP | TSopt | 10 |
+--------+--------+--------+--------+
| TSval timestamp |
+--------+--------+--------+--------+
| TSecr timestamp |
+--------+--------+--------+--------+ Notera NOP stoppning visas före tidsstämpel, inte i slutet som du kanske tror. Observera även RFC uttryckligen säger att detta är för "icke-SYN segment" och att det är "rekommenderat", krävs inte. Verkar dock att de flesta operativsystem följa denna rekommendation och alltid plats stoppning innan Kind och bytes längd. Jag har kollat Windows, Linux, Mac, olika hårdvara, osv, och de alla lägger stoppning i början.
Så vi kan räkna med att detta är "standard", eller hur? Inte riktigt. Sidan 17 av RFC 793 beskriver NOP så här:
Detta alternativ kod får användas mellan alternativ, till exempel för att
anpassa början av en efterföljande alternativ på en ordgräns.
Det finns ingen garanti för att avsändare kommer att använda detta alternativ, så
mottagare måste vara beredd att bearbeta alternativ även om de inte
inte börja på en ordgräns. Med andra ord, det är inte bara att NOP kan eller inte kan dyka upp i början, kanske NOP inte användas alls! Det är helt lagligt att layouten TCP alternativet fältet utan NOP stoppning och bara använda Slut på Alternativlista som fyllmedel i slutet för att uppnå den rätta gränsen.
Så vad hamnar vi med för ett filter? Om vi räknar på NOP innan det alternativ vi sluta med ett filter som ser ut så här:
tcp [13] & 2 = 2 och tcp [12] & 240> 80 och ((tcp [20] = 1 och tcp [21:02] = 0 × 0303) eller (tcp [24] = 1 och tcp [25:2 ] = 0 × 0303) eller (tcp [28] = 1 och tcp [29:2] = 0 × 0303) eller (tcp [32] = 1 och tcp [33:2] = 0 × 0303) eller (tcp [ 36] = 1 och tcp [37:2] = 0 × 0303) eller (tcp [40] = 1 och tcp [41:2] = 0 × 0303) eller (tcp [44] = 1 och tcp [45:2 ] = 0 × 0303) eller (tcp [48] = 1 och tcp [49:2] = 0 × 0303) eller (tcp [52] = 1 och tcp [53:2] = 0 × 0303) eller (tcp [ 56] = 1 och tcp [57:2] = 0 × 0303))
Att bryta ner vad detta filter gör:
- Bara kolla SYN & SYN / ACK-paket: tcp [13] & 2 = 2
- TCP-huvud är större än 20 byte (alternativ anges): tcp [12] & 240> 80
- Kontrollera den första byten i varje fyra byte gräns för NOP: tcp [20] = 1, tcp [24 = 1, ...
- Kontrollera de kommande två byte för att se om Kind = 3 och längd = 3: tcp [21:02] = 0 × 0303, tcp [25:2] = 0 × 0303, ...
Men om vi vill se till att vi fångar alla möjligheter om ett system inte genomför NOP vi sluta med:
tcp [13] & 2 = 2 och tcp [12] & 240> 80 och (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)
Skillnaden med detta filter är att vi kontrollerar Typ = 3 och längd = 3 hela vägen igenom alternativen området (som Elizabeth föreslår).
Kan någon av dessa filter genererar falsklarm? Absolut! Två möjligheter:
- Värdet av Timestamp kan matcha det mönster vi letar efter.
- Filtret tar en 40 fält byte alternativ. Det kan vara mindre med dessa värden i nyttolasten.
Så vilket filter bör du använda? Den första kommer att generera färre falsklarm, men missar system som är RFC-kompatibla, men skiljer sig från normen. Den andra kommer alltid att fånga Fönster Skala om den har ställts in, men chansen till ett falskt positivt är högre.
Jag ska utse Elizabeth som vinnare av utmaningen. Några andra var lika nära men hon var den enda med modet att lägga sin tankegång i kommentarerna. Jag kommer att dela ut ett andrapris till Jeff som kom upp med den här lösningen delvis skojar runt:
tcpdump-nn | grep 'wscale'> wscale-matches.txt
Detta kommer inte att generera en faktisk fånga paket, men du kunde göra en:
tcpdump-nn-X-s 0 | grep 'wscale'> wscale-matches.txt
Och kör sedan ut genom txt2cap att få den tillbaka in pcap format. Han följde inte utmaningen specifikt, men du har måste ge beröm för att tänka utanför boxen eftersom detta fixar alla falska positiva frågor.
Elizabeth och Jeff, jag kommer att kontakta dig både via e-post. Grattis!
